Scribit Ian Eslick dies 09/11/2006 hora 17:26: > If the base class is persistent, then it's transient/persistent slot > values will be propagated to the subclass. If it's a normal class, > then all its slots become transient - their normal properties if in > the baseclass.
I understand this point of view. > If you have your head pretty deeply inside CLOS then I think the > current behavior is more consistent. I have a strong C++ background, and almost everything I know about OOP, I learned it with C++. It is a very different view of objects indeed. I must say that only the multipe dispatch and the concept of MOP were revolutions for me... (should I add I love them...) > Why not override the base class slots you want to persist explicitly > by redeclaring the slots to get the new semantics for storage while > maintaining current functioning of base class methods? Well, it breaks some use of the class hierarchy: you could alter all the hierarchy by changing it's base class. With the current scheme, if you add a slot, you have to track where it would be of any use and add it to the overridden slots. In this case, the class option is of great interest. > I was going to clean up the MOP implementation using :closer-mop, but > I'm not sure it happens to have the fixes for the lisp-specific parts > of the MOP that elephant uses so I'll back out those changes so the > current tree doesn't get polluted while you're hacking on the MOP. Don't ever stop your cleaning for me. I'm not sure when I will be able to give you a usable patch, and I've already begun to try and play with closer-mop, so in fact it could help me if you switch the MOP part to it. Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
