<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
To quote a folksy expression from Texas, "I ain't got a dog in this fight."<BR>
<BR>
I'm glad Pierre and Ian are working this out, however.<BR>
<BR>
<BR>
On Tue, 2006-11-07 at 17:44 +0100, Pierre THIERRY wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Scribit Ian Eslick dies 11/10/2006 hora 11:29:</FONT>
<FONT COLOR="#000000">> If you have a non-persistent base class, should the semantics of the</FONT>
<FONT COLOR="#000000">> slot storage change based on whether it's included in a persistent</FONT>
<FONT COLOR="#000000">> subclass?</FONT>
<FONT COLOR="#000000">When you inherit from a class, you expect the sub-class to have all the</FONT>
<FONT COLOR="#000000">properties that the super-class has, plus it's specific ones. I think</FONT>
<FONT COLOR="#000000">the current design of Elephant breaks that expectation.</FONT>
<FONT COLOR="#000000">I really think that the most sensible way of dealing with this is to</FONT>
<FONT COLOR="#000000">make all effective slots persistent, and provide options to alter that</FONT>
<FONT COLOR="#000000">behaviour. This :persist option could accept either a keyword for a</FONT>
<FONT COLOR="#000000">predefined persistence scheme or a list of slots.</FONT>
<FONT COLOR="#000000">Let's take a base class:</FONT>
<FONT COLOR="#000000">(defclass foo ()</FONT>
<FONT COLOR="#000000"> ((bar)))</FONT>
<FONT COLOR="#000000">We could have the following sub-classes:</FONT>
<FONT COLOR="#000000">(defclass sub-foo-1 (foo)</FONT>
<FONT COLOR="#000000"> ((baz)</FONT>
<FONT COLOR="#000000"> (fubar))</FONT>
<FONT COLOR="#000000"> (:metaclass persistent-metaclass))</FONT>
<FONT COLOR="#000000"> ; persistent-slots: (bar baz fubar)</FONT>
<FONT COLOR="#000000"> ; this could be (:persist :effective-slots)</FONT>
<FONT COLOR="#000000">(defclass sub-foo-2 (foo)</FONT>
<FONT COLOR="#000000"> ((baz)</FONT>
<FONT COLOR="#000000"> (fubar))</FONT>
<FONT COLOR="#000000"> (:metaclass persistent-metaclass)</FONT>
<FONT COLOR="#000000"> (:persist :direct-slots))</FONT>
<FONT COLOR="#000000"> ; persistent-slots: (baz fubar)</FONT>
<FONT COLOR="#000000">(defclass sub-foo-3 (foo)</FONT>
<FONT COLOR="#000000"> ((baz)</FONT>
<FONT COLOR="#000000"> (fubar))</FONT>
<FONT COLOR="#000000"> (:metaclass persistent-metaclass)</FONT>
<FONT COLOR="#000000"> (:persist :inherited-slots))</FONT>
<FONT COLOR="#000000"> ; persistent-slots: (bar)</FONT>
<FONT COLOR="#000000">(defclass sub-foo-4 (foo)</FONT>
<FONT COLOR="#000000"> ((baz)</FONT>
<FONT COLOR="#000000"> (fubar))</FONT>
<FONT COLOR="#000000"> (:metaclass persistent-metaclass)</FONT>
<FONT COLOR="#000000"> (:persist (bar baz)))</FONT>
<FONT COLOR="#000000"> ; persistent-slots: (bar baz)</FONT>
<FONT COLOR="#000000">There could also be a :transient option to achieve the opposite...</FONT>
<FONT COLOR="#000000">As I never really used the MOP, I'm not sure how it is harder to achieve</FONT>
<FONT COLOR="#000000">than the current behaviour, but I think the flexibility and</FONT>
<FONT COLOR="#000000">expressiveness of this is worth the effort.</FONT>
<FONT COLOR="#000000">> Now what happens if we inherit from sub-foo above?</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> (defclass sub-sub-foo (sub-foo)</FONT>
<FONT COLOR="#000000">> ((qux))</FONT>
<FONT COLOR="#000000">> (:metaclass ele:persistent-metaclass)) ;; protocol will assert an</FONT>
<FONT COLOR="#000000">> error if subclass of persistent isn't persistent</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> In this case the normal CLOS machinery will pick up the non-direct slots</FONT>
<FONT COLOR="#000000">> from subclasses and the bar and myfoo</FONT>
<FONT COLOR="#000000">> slots will be non-transient. There may be a way to override this to</FONT>
<FONT COLOR="#000000">> search for subclass specifications of :persist-subclass-slots and then</FONT>
<FONT COLOR="#000000">> go ahead and promote :transient effective slots to :persistent but all</FONT>
<FONT COLOR="#000000">> the cases and interactions can start to become hairy.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> I think the currently policy is the simplest and least bug prone, even</FONT>
<FONT COLOR="#000000">> though it forces the increased verboseness of the first example.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> Thoughts?</FONT>
<FONT COLOR="#000000">I definitely agree on the hairiness of a more expressive alternative...</FONT>
<FONT COLOR="#000000">I'd like to come up with a proposal for a sensible and consistent of</FONT>
<FONT COLOR="#000000">dealing with these corner cases elegantly. I'll try to come up with a</FONT>
<FONT COLOR="#000000">patch also, if I manage to grasp how MOP works.</FONT>
<FONT COLOR="#000000">Hopefully,</FONT>
<FONT COLOR="#000000">Nowhere man</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">elephant-devel site list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</A></FONT>
<FONT COLOR="#000000"><A HREF="http://common-lisp.net/mailman/listinfo/elephant-devel">http://common-lisp.net/mailman/listinfo/elephant-devel</A></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>