[elephant-devel] Elephant and inheritance

[Pierre THIERRY]

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
-- 
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/20061107/646e657a/attachment.sig>