[elephant-devel] Elephant and inheritance

[Andrew Blumberg]

as the designer of this part of elephant, maybe i'll add my opinions on 
the subject.

the "usage profile" i envisioned when i wrote the MOP code was one (which 
reflects my coding habits) where there are a lot of little 
non-persistent mixin classes which affect dispatch and sometimes store 
intermediate information.  very rarely should the slots associated to 
these mixins be made persistent when the mixin is added to a persistent 
class; you want it when you want it, but not by default.

moreover, whether or not elephant breaks the expectation about sub-class 
behavior depends on what you think the property in of persistent classes 
is --- since i tend to think of that property as "might have some 
persistent slots", not "all slots are persistent", i regard the current 
behavior as consistent with my expectations.  you might or might not think 
that's a reasonable way to view what persistence means, but it is 
coherent anyway.

finally, i don't think the technical hair of adjusting the behavior of the 
mop here should be too bad (or rather, it won't be any hairier then the 
getting the current behavior to work correctly was), if that's what you 
want.  i'll be happy to answer questions/ look at code if that will be 
helpful.

 								- andrew

On Tue, 7 Nov 2006, Pierre THIERRY wrote:

> Scribit Ian Eslick dies 11/10/2006 hora 11:29:
>> 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
>