"Pascal J. Bourguignon" <p...@informatimago.com>: > Marko Rauhamaa <ma...@pacujo.net> writes: > >> Similarly, in my mind, objects don't have slots, they interact. > > You are right. Slots are an implementation detail. Notice that you > have them in all (common) OO systems. But the difference with CLOS, > with the MOP, (I don't know if GOOPS implements the MOP, Meta Object > Protocol), slots are reified as first class objects, and can be added > or removed from a class (therefore, to all its instances). > > This allows you to forget slots as features of classes, but instead, > as an implementation mechanism for certain kinds of relationships. So > you can define a macro define-associations and use it to describe how > your objects interrelate and interact with others, and this macro will > add slots as needed to implement those associations: > > https://github.com/informatimago/abnotation/blob/master/src/core/model.lisp > https://github.com/informatimago/lisp/blob/master/clext/association.lisp#L575
GOOPS seems to have much of that machinery. I don't know if I find it all that useful. I'm fine with the notion that the object itself decides what methods it offers. Amending classes or objects from the outside or after the fact might come in handy but is not high on my shopping list. However, GOOPS doesn't seem to allow me to control the object construction as simply as the "lesser" OO systems do. What's more, GOOPS programs don't look "Schemey" any more. That's why I have turned away from GOOPS and returned to the basics: <URL: https://www.gnu.org/software/guile/manual/html_node/OO-Closur e.html#OO-Closure> The simpleton.scm object system I posted the other day adds only a thin sugar coating on this approach. Marko
