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
