[elephant-devel] Elephant and inheritance

[Ian Eslick]

PS - I'd vote to keep the current defaults but allow :persist
:inherited-slots to override that.  This avoids breaking backward
compatibility for the existing user base.  If enough people prefer that
as the default we can fix it at some point in the future and force the
(small) community to upgrade.

Cheers,
Ian

Pierre THIERRY wrote:
>
>> If you have a non-persistent base class, should the semantics of the
>> slot storage change based on whether it's included in a persistent
>> subclass?
>>     
>
> 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.
>
> 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