Re: GOOPs, MOP and slots

[Andy Wingo]

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 <address@hidden> 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/