I thought that the last parameter wasn't secret (although I don't know
where I would look for it in the docs). Passing true causes the node to
initialize immediately rather than being added to the instantiator
queue, right?
This is used in various places in the components, basetab comes to mind,
for example:
if (this.content == null) {
this.content = new basetabscontent(this, {}, null,
true);
On Sat, May 20, 2006 at 9:49 AM, P T Withington wrote:
> 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
