🚀 go-pugleaf

(I was asking for opinions on how far teh MOP could be pushed):

>>I have been doing some work which involves taking over the
>>slot storage for metaclass instances.  The purpose in doing
>>so is to experiment with a fully versioned environment, where
>>the values of slots, as well as the slots hemselves are 
>>versioned.  Behaviors get version too, for that
>>matter. 

Harely Davies replies:

>I think this is exactly the sort of extension that a MOP should
>allow.  It would be sad if this is impossible using the CLOS MOP.
>Perhaps some more detail on why you think this may never work would
>help.  I know that at least one of our clients is working on something
>similar using the TELOS MOP, and has not yet encountered any
>fundamental difficulties.

Well, I'm still stalking the problem, but the upshot is that taking over
the storage for the slots of the class itself is tripping over an
optimization that avoids re-running initforms, by keeping a copy of a 
partially initialized instance around.  The optimization runs 
shared-initialize only for 'vanilla' slots, but my take over of 
storage means there are no 'vanilla' slots; then an :after method
on shared-initialize for classes gets upset, since several vital 
slots haven't been initialized.

I am sure I *can* make this work, but am also equally sure that this is
an example of a need for a better way to specify what's happening here.

For example, to take a silly extreme, I certainly couldn't take over 
slot storage for the class itself and start giving back random values and 
expect that to work.

But how about setting up slot storage that works in 'versions'; starting
from some consistent point, all the setf's are captured in a 'version', which 
may get rolled back to that prior point.  Should that be expected to work?
How can I tell?  How can the MOP implementor, who is working on 
some caching optimization know that I may be doing something of the sort?

   ...Tom M