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. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
