From killerstorm at newmail.ru Sun Oct 2 16:03:01 2011 From: killerstorm at newmail.ru (Alex Mizrahi) Date: Sun, 2 Oct 2011 19:03:01 +0300 Subject: [elephant-devel] Reason for References: <2076A344-0510-46CE-B037-77828AF25C38@media.mit.edu> <53CACEFB-78A2-40A4-B38E-65E4FB58FE3C@media.mit.edu> Message-ID: 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. From hugo_duncan at yahoo.com Thu Oct 13 07:17:56 2011 From: hugo_duncan at yahoo.com (Hugo Duncan) Date: Thu, 13 Oct 2011 00:17:56 -0700 (PDT) Subject: [elephant-devel] (no subject) Message-ID: <1318490276.91926.yint-ygo-j2me@web125413.mail.ne1.yahoo.com> ..Sex all night long! http://e-aulas.com.ar/com.friend.php?zyrs=18a3