I'm thinking that might be the right answer. LzNode already takes most of its arguments as a list in the attributes parameter. Is there any reason to break out parent and children (and the secret 'instcall' param)?
On 2006-05-20, at 11:31 EDT, Jim Grandy wrote: > We could simulate keyword arguments by requiring that the > initializer take just one argument: an object containing key/value > pairs. > > By coincidence, I've been putting some time into fleshing out the > formal Traits RFC. This just discusses LZX-level syntax and > (informal) semantics, it doesn't touch on how traits surface in the > new class regime. I'll send out a notice when I've got a new draft; > right now I'm muddling through some conceptual stuff and the text > is, er, in progress. > > On May 20, 2006, at 4:24 AM, 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
