Hi David, A pleasure to get such nice questions about GOOPS :) I have a love/hate relationship with the thing; I've spent a lot of time hacking it but I don't really use it these days.
On Fri 11 May 2012 14:19, David SpÄngberg <da...@tunna.org> writes: > In the CLOS-like language Closette presented in AMOP (The Art of the > Metaobject Protocol) there is a generic method named > `slot-value-using-class' which is used to access the slots of specific > instances. For example this method is used by `slot-value' (`slot-ref' > in GOOPs). In AMOP this generic method is used to implement classes > where every access and modification of slots is logged. It is also used > to implement a class with a kind of dynamic allocation of slots. > > In GOOPs however the corresponding function `slot-ref-using-class' is > not generic. My question is if someone know why this is the case? Or > maybe someone can point me to some documentation which may contain > information about this? I don't know why it's not generic. Have you taken a look at the corresponding code in Stklos? In general for this kind of question you have to think that GOOPS was implemented from about 1998 to 2002. Since then it has not changed much. I guess the largest change was rewriting parts of it for Guile 2.0, as it used interpreter-specific hacks. However my goal was keeping functionality, not extending the MOP. It could be that making it generic is the right thing, and if Kiczales does it and CLOS does it, then hey, we probably should, too. Basically you need to look at the problem and decide the right thing. It's a bit terrifying in some ways, to modify a really intricate piece of code without a maintainer to tell you what to do, but it's quite possible to do. Do I have it right that you are in Sweden? You should see if you can convince Mikael Djurfeldt to join you for dinner some day ;-) > My usecase if anyone wanted to know is to implement python-like > attributes as slots for instances. I.e. slots which is not class > specific but instead is only related to the current instance. These > slots should be accessible by using the standard `slot-ref' and > `slot-set! functions in GOOPs. I would consider using eql specializers for the accessors. That way you can specialize to an instance. Of course that's another unimplemented part of the MOP, this time in generic functions. Generic functions are a bit tricky for that, though; for best performance, you need a cache per call site -- an inline cache, as pioneered by self (and smalltalk-80 before it) -- but GOOPS's cache is per-generic. It works, but isn't optimal. I'm not sure how to fix that. > My guess is that by making `slot-ref-using-class' generic makes it > impossible to memoize slot locations for these kinds of classes. Could be. The MOP is all about permitting efficiency when you use the standard classes. It doesn't prohibit efficiency for others, though, and since GOOPS is mostly written in Scheme now, things should be more flexible. Happy hacking with GOOPS, Andy -- http://wingolog.org/