🚀 go-pugleaf

In article <65415@cup.portal.com> Thomas_E_Morgan@cup.portal.com writes:
>[Re: Using the MOP to change the slot storage mechanisms of the classes
>     themselves.]
>
>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.
>
>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.
>
>[...]
>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 

Indeed, I don't see any problem in terms of the MOP with re-defining the
slot-storage mechanisms for the metaclasses themselves.  The difficulty,
however, is "bootstrapping" the slot storage mechanism before (or while)
the class is being finalized.  Particularly when accessing a metaclass'
slot value with the new slot storage mechanism relies on accessing other
metaclass' slot values that also use the new slot storage mechanism.

There are two slot bootstrapping concerns then that the person writing
the metaclass has to be concerned about.  First is that his own code
doesn't access a slot before the vital slots have been initialized.
That the implementor has control over.  The second is that the CLOS
code doesn't access such slots before the vital slots have been
initialized, while finalizing the class.  This, I believe, is your
problem in July 92 PCL.  Here you don't really have any control, because
the MOP doesn't define the order metaclass slots are accessed during
finalization, so it depends solely on what sort of optimization tricks
the CLOS uses.

Probably the best way to get around this potential problem is to make
sure that any metaclass slots that are vital to the new slot storage
mechanism are completely initialized in whatever fashion necessary
before class finalization.  In fact, they probably should be completely
initialized -- and the new slot storage mechanism completely working --
before any of the other slots on the metaclass are initialized -- i.e.
with a :before or :around method on shared-initialize.  If that's the
case, and the modified slot-access (slot-value-using-class, etc.) code
works for the metaclass right from the very beginning (i.e. before
the metaclass instance's slots are initialized by the primary
shared-initialize method), then there shouldn't be any problems with
the AMOP itself.

- Trent Lange