I looked at this, but I have to admit to also being somewhat lost. I didn't do this refactoring, and none of this stuff is in trunk. I agree that it doesn't appear to make much sense as it's written, but I didn't look at closely. I can look more closely at this if we can't find the original implementor/perpetrator.
A On Sep 15, P T Withington wrote: [snip] > > ---------- > > > > LzDataElement defines variables nodeName, childNodes, and attributes. But > > these are actually used in LzDataElementTrait. Shouldn't these lines, > > > > var nodeName = null; > > var childNodes = null; > > var attributes = null; > > > > be moved to LzDataElementTrait? > > That seems logical. In fact, LzDataSet also inherits from LzDataElementTrait, > but does not define any of those slots, so how could it even work? > > This comment, from LzDataNode, however, makes me think that it is important > that these slots are not defined in the trait: > > // Also N.B.: If this _does_ descend from LzNode and has initial > // data, childNodes will have already been set by applyArgs, so > // don't set it here! > > I'm not going to move them until we understand this better. > > > LzDataElement extends LzDataElementTrait and LzDataNode. Both of these > > parent classes use childNodes. Is this why classNodes is defined in > > LzDataElement and not LzDataElementTrait? > > Hopefully someone else can shed some light here. _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
