Well, in LZX they are. But the new class regime simply provides them as something that you can mix in to any class hierarchy. Which is nice, because we were able to use them for LzDataNode and LzDataElement. But perhaps you will say that LzDataNode _should_ have the same initialization signature as LzNode?
LzDataElement's initialization signature is (name, attributes, children), whereas LzNode's is (parent, attributes, children, <reserved>), and name is simply another attribute. And LzDataElement seems to derive it's parent somehow, rather than taking it explicitly. It seems to me that these two could be brought more into line, perhaps they should be made more DOM-ish even? On 2006-05-20, at 12:23 EDT, Adam Wolff wrote: > 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
