[elephant-devel] Elephant and inheritance

[Ian Eslick]

> When you inherit from a class, you expect the sub-class to have all the
> properties that the super-class has, plus it's specific ones. I think
> the current design of Elephant breaks that expectation.
>   
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.

If you want all slots to be persistent then you should inherit from
persistent base classes and build up a persistent hierarchy in the
background.

Of course this depends on how you read the :metaclass semantics.  Am I
making the entire hierarchy persistent or just the current class?  If
you have your head pretty deeply inside CLOS then I think the current
behavior is more consistent.  However, if you're used to more of a Java
object model then reading :metaclass as specifying a property for all
the effective slots of the current class is more appropriate. 

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?

Class options are a little annoying to implement and when I first
figured out how the MOP worked, and how it was implemented in Elephant I
have to admit it took me quite awhile and I had used Lisp pretty heavily
for a year and half.

However, I'm happy to support a :persist class option if you can figure
out how to implement.  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.

Let me know what you're thinking so we can coordinate any changes (and I
can provide some support and answer questions).

Ian
> I really think that the most sensible way of dealing with this is to
> make all effective slots persistent, and provide options to alter that
> behaviour. This :persist option could accept either a keyword for a
> predefined persistence scheme or a list of slots.
>
> Let's take a base class:
>
> (defclass foo ()
>   ((bar)))
>
> We could have the following sub-classes:
>
> (defclass sub-foo-1 (foo)
>   ((baz)
>    (fubar))
>   (:metaclass persistent-metaclass))
>   ; persistent-slots: (bar baz fubar)
>   ; this could be (:persist :effective-slots)
>
> (defclass sub-foo-2 (foo)
>   ((baz)
>    (fubar))
>   (:metaclass persistent-metaclass)
>   (:persist :direct-slots))
>   ; persistent-slots: (baz fubar)
>
> (defclass sub-foo-3 (foo)
>   ((baz)
>    (fubar))
>   (:metaclass persistent-metaclass)
>   (:persist :inherited-slots))
>   ; persistent-slots: (bar)
>
> (defclass sub-foo-4 (foo)
>   ((baz)
>    (fubar))
>   (:metaclass persistent-metaclass)
>   (:persist (bar baz)))
>   ; persistent-slots: (bar baz)
>
> There could also be a :transient option to achieve the opposite...
>
> As I never really used the MOP, I'm not sure how it is harder to achieve
> than the current behaviour, but I think the flexibility and
> expressiveness of this is worth the effort.
>
>   
>> Now what happens if we inherit from sub-foo above?
>>
>> (defclass sub-sub-foo (sub-foo)
>>    ((qux))
>>    (:metaclass ele:persistent-metaclass))  ;; protocol will assert an
>> error if subclass of persistent isn't persistent
>>
>> In this case the normal CLOS machinery will pick up the non-direct slots
>> from subclasses and the bar and myfoo
>> slots will be non-transient.  There may be a way to override this to
>> search for subclass specifications of :persist-subclass-slots and then
>> go ahead and promote :transient effective slots to :persistent but all
>> the cases and interactions can start to become hairy.
>>
>> I think the currently policy is the simplest and least bug prone, even
>> though it forces the increased verboseness of the first example.
>>
>> Thoughts?
>>     
>
> I definitely agree on the hairiness of a more expressive alternative...
> I'd like to come up with a proposal for a sensible and consistent of
> dealing with these corner cases elegantly. I'll try to come up with a
> patch also, if I manage to grasp how MOP works.
>
> Hopefully,
> Nowhere man
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel