This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Per Bothner writes: > This does sound rather expensive, but I think one could come up with > clever ideas to keep things reasonably fast, especially for teh > single-dispatch case. The real question is: How well would such a > system work for the programmer? I don't know. I would be very > curious to know. as a common programmer (w/ no experience designing object-systems), i tend to think of modules as embodying a certain type, that is the type of object that the functions in the module can apply to. this usually is a primitive type conceptually cast; eg., a "schedule" type is really a list w/ certain properties, and the scheduling module is responsible for creation, update and, in general, invariance maintenance of this type. i'd like to schedule things other than lists, however, and so under the current system, would write another module to wrap the list-implemented scheduling module to handle, say arrays. so now i have two modules. it sounds like what you're proposing is that this wrapping be done somewhat automatically, w/ the object system preserving semantics by generating code that understands what types in the first module are substitutable by other types, and using this understanding to perhaps translate one type to another. is wrapping what you're talking about? if not, i don't see how code can be made generic w/o changing the code -- does the object system require back-annotation to current code? or are you proposing that a module declare its type "applicability" and thus be open to (run-time?) selection based on type? pardon my ignorance, i will go read up on MOP. thi