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] |
mike@olan.com (Michael N. Livshin) writes: > 1. > I took a look at the Guile sources and found that Mikael > started implementing some sort of metaclass-based OO system, > and that he defined an "operator metaclass". Yes, GOOPS will be similar to tiny-clos and STKlos. > 2. > It appears to me that the evaluator is not yet aware of > the fact that something other than closure can be apply'd. > Is it true or had I overlooked something? Other things than closures can be applied, however the user-level interface to these evaluator facilities is not finished. The reason why I put it in there now is that I'm using it in the STk interface port. > 3. > I was going to see how to add simple single-dispatch generics > to Guile. > <rant> > Records and single-dispatch generics are all the OO support > any reasonable design should ever need. None of that hyped-up > inheritance stuff. > </rant> I think inheritance is a powerful tool, useful for structuring programs and for re-use of existing code. > Ahem, anyway, after looking at Mikael's OO stuff, I thought that > perhaps the right way to implement generics would be to define > a class of the "operator metaclass". It is probably not, depending on how you want to implement them. A class with an operator metaclass has the dispatcher stored in the class object. A generic function is more efficient if the dispatcher is stored in the generic function object itself, i. e., in the instance. (This is because it already knows what function has been requested, so it only needs to bother about the arguments.) So, a generic function should probably be a subclass of the entity class which is an instance of the standard metaclass. [...] > Should I just shut up and wait till GOOPS surfs up? I'm sorry, but in this case I think this is a good idea. The reason is that since GOOPS will provide generic functions, it doesn't seem useful to implement a separate generic function facility. The basics of GOOPS may surf up during the Christmas holiday. :) But perhaps I can contact you again if/when I discover that we can work on this together? Best regards, /mdj