[elephant-devel] Elephant and inheritance

[Robert L. Read]

To quote a folksy expression from Texas, "I ain't got a dog in this
fight."

I'm glad Pierre and Ian are working this out, however.


On Tue, 2006-11-07 at 17:44 +0100, 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
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20061107/1960b385/attachment.html>