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
