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
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
