I recall there being problems taking base class injection out of shared-initialize - can initialize-instance manipulate the class precedence list and direct superclasses at that point in the instance initialization?
It occurs to me that, the easiest way to fix this is by policy; remove the functionality in 'shared-initialize (persistent-metaclass)' from the MOP entirely and mandate that persistent classes use the defpclass macro, or that users inherit from persistent-object manually. The macro can do the error checking and base-class injection and be done with it. The tests would have to be updated to stop using the explicit metaclass. I can make the change and update the tests and then look into the other issues if you concur. Thanks, Ian On Sep 29, 2011, at 12:57 AM, Alex Mizrahi wrote: >> I also made a change for ccl so we don't inject the class if the >> dependencies argument was not provided (vs passing it along as a nil >> argument). I'll look at the alternate placement. > > AMOP spec says that users shouldn't add methods to SHARED-INITIALIZE of a > metaclass. I think it can be moved to INITIALIZE-INSTANCE and > REINITIALIZE-INSTANCE, as they are allowed, and that would also prevent > problems with internal updates as these functions are not called on > update-instance-for-*. (I.e. you can get rid of the check of whether > direct-superclasses were passed or not in that case.) > > So that could be a conservative fix (more like bringing it up to the spec) > which doesn't change the implementation much. > > COMPUTE-PRECEDENCE-LIST sounds like a cleaner way to do it (if we don't > really care for DIRECT superclasses), but I haven't read AMOP on this yet, so > it is more like a guess. > >> These get ccl to pass all but one test. >> Where are you with getting sbcl to build/pass? I'm testing with 1.0.56 > > IIRC both CCL and SBCL were passing all tests but CACHING-STYLE-REQUIRED. > (Again some MOP part which doesn't work.) > > But then I've fixed the test suite itself and got more failures. :) > > Can you please check inhibit-rollback (in testconditions) after applying my > patches? It crashes lisp, as I understand, through corrupting BDB state. > (Problem was previously hidden because of "ignore-conditions".) > > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
