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 -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
