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] |
>> Can you explain how you would implement (setter ...) ? I can't quite >> see how it works. > >Well, each procedure optionally has a setter attribute associated with it, and >(setter PROC) retrieves the setter attribute. If there is no setter, an eror is >signalled. Hmm. Procedures with values associated. That seems a bit of a radical departure from Scheme. To do that even vaguely efficiently, the setter has to be part of the procedure object. But putting custom things in procedure objects (or other existing objects for that matter) is not a Schemey thing. I could perhaps understand if this opened up some wonderful new aspect of Scheme programming, or some whole new paradigm, but it seems like a hack to do something better served by a much more general mechanism, which is generic functions. Or maybe I'm missing something, I don't know. >For how implement this in Guile? I leave that to Guile >implementors. One reason I preferred to start from scratch >with Kawa is that having an object-oriented implementation >core is easier to extend. Yeah, but I totally fail to see how this idea is OO anyway. If you have a method called "address" which returns a slot in a certain object... Who is to say how many classes in the system have an address procedure with the same name? So you still have to have a generic function to work out exactly which address member we are talking about. So a generic function must be called anyway, so why muck around with this back-door method, when you can call what you want directly? Which by the way, reminds me of another reason why I don't think methods should be directly associated with a particular class in lisp or scheme. Because in CLOS or any lisp style OO system, the method name comes first (method object other args) it has to be the (method) procedure which does the actual dispatch. And since many totally unrelated classes can have methods with the same name, it stands to reason that the dispatch mechanism should be global.