I had always assumed that traits were limited to LzNode and its 
inheritors.

A

On May 20, P T Withington wrote:

> So Henry and I got our first 'real life' experience with Traits recently.
> Trying to remodularize the data classes to use Traits instead of
> 'cheesyMultipleInheritance'.  It mostly worked.  It was very helpful that
> Traits have a 'class initialize method' that gets to initialize the class
> prototype after the superclass has built it.  This allowed us to make
> LzDataset setters actually work.
> 
> BUT, one thing that has not been obvious in our toy examples so far is that
> the 'instance initialize method' of a Trait (which runs each time an instance
> is created) _has_ to 1: call the superclass instance initialzer (first), and
> hence 2: must have the same signature as the superclass initializer.
> 
> This was not the case for the old 'cheesyMultipleInheritance' which
> essentially just discarded the initializers for all but the superclass (since
> the intitializer was the constructor).  When we blindly converted constructors
> to initializers, we ended up with a mess.  In the end, it turned out that
> neither of the Traits (LzDataNode and LzDataElementTrait) really needed
> instance initializers at all.  But if they had, we would have been in a
> quandary, because the two superclasses that they get mixed in to have
> different initialize signatures.
> 
> Just something to think about when you are factoring classes into traits...
> 
> [Dylan/Lisp P.S.:  These languages punt the signature issue by requiring all
> args to make/initialize to be keyword arguments.  Hey, keyword arguments...
> wouldn't that be nice.]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Reply via email to