[elephant-devel] Elephant and inheritance

[Pierre THIERRY]

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
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20061109/c294f365/attachment.sig>