The LzDataElement method signature follows the W3C DOM spec. On May 20, P T Withington wrote:
> 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
