[elephant-devel] Reason for

[Alex Mizrahi]

 IE> I recall there being problems taking base class injection out of
 IE> shared-initialize - can initialize-instance manipulate the class
 IE> precedence list and direct superclasses at that point in the instance
 IE> initialization?

I think it should work the same way -- INITIALIZE-INSTANCE :around calls 
INITIALIZE-INSTANCE primary method with a modified arglist, which then calls 
SHARED-INITIALIZE with that list.
I don't see why this wouldn't work when SHARED-INITIALIZE works. MOP 
implementation could bypass normal initialization protocol, but then 
SHARED-INITIALIZE method wouldn't work either.

My guess was that it was written this way to avoid duplicating code for 
INITIALIZE-INSTANCE and REINITIALIZE-INSTANCE, if it wasn't meta- stuff 
shared-initialize would be a right place to do it.

 IE> It occurs to me that, the easiest way to fix this is by policy; remove
 IE> the functionality in 'shared-initialize (persistent-metaclass)' from
 IE> the MOP entirely and mandate that persistent classes use the defpclass
 IE> macro, or that users inherit from persistent-object manually.  The
 IE> macro can do the error checking and base-class injection and be done
 IE> with it.  The tests would have to be updated to stop using the explicit
 IE> metaclass.

I don't see much value in this 'forgiving' behaviour either.
But some kind of warning wouldn't hurt.