Question:
Is it expected that I could have default options on a class and then
my subclasses should inherit those options?
On 2006-09-18, at 10:55 EDT, Adam Wolff wrote:
> Don't know if this was already discussed, but my preference would
> be to
> put an empty hash on the LzNode prototype. Then setOption could
> test for
> it and initialize the slot with a new hash before setting only if
> this.options == LzNode.prototype.options. Most nodes don't have
> options,
> so it's really a waste to give an empty hash to each one.
>
> A
>
> On Sep 18, Henry Minsky wrote:
>
>> Did we ever put in a patch for this?
>>
>> The simplest one would be
>>
>> var options = {};
>>
>> in LzNode.lzs I guess.
>>
>> The other alternative would be to rewrite the callers to use
>> getOption() ,
>> which checks for null, instead of
>> directly accessing the options slot, but that would cost a
>> function call...
>>
>>
>> On 9/15/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>
>>> One work-around is to initialize the options slot in the initialize
>>> method of the class LzNode, that will ensure that each instance has
>>> it's own hash. There is a possibility that could be an efficiency
>>> issue if most nodes don't have options.
>>>
>>>
>>> On 2006-09-15, at 10:51 EDT, Henry Minsky wrote:
>>>
>>>> I would just be careful about making sure that the object which is
>>>> created
>>>> is not shared among multiple instances; in other words
>>>> the initializer for the instance needs to make a new object.
>>>>
>>>> We had an issue like this with the subnodes or subviews array early
>>>> on, I
>>>> forget how we solved it, I am remembering something
>>>> about how the accessor
>>>> method for adding child views checked if it was an empty array ,
>>>> and if it
>>>> was trying to add an entry to the empty array, it created a new
>>>> array. So
>>>> the default empty array was shared among all instances of view but
>>>> a fresh
>>>> object was consed up the first time it was needed.
>>>>
>>>>
>>>>
>>>> On 9/15/06, Philip Romanik <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Hi Henry,
>>>>>
>>>>> I started looking at his a little bit at this issue. I bypassed
>>>>> the
>>>>> initial
>>>>> error and ran into something else. The component code expects that
>>>>> the
>>>>> options property to be non-null.
>>>>>
>>>>> For example, in basewindow.lzx:
>>>>>
>>>>> <method name="construct" args="parent,args">
>>>>> var wlist = parent.options['windowlist'];
>>>>> if (wlist == null || typeof wlist == "undefined") {
>>>>> wlist = [];
>>>>> parent.setOption('windowlist', wlist);
>>>>> }
>>>>> super.construct(parent,args);
>>>>> </method>
>>>>>
>>>>>
>>>>> this is failing because parent.options is null. In LzNode.lzs,
>>>>> options is
>>>>> null until someone calls setOption() for the first time. Is
>>>>> this an
>>>>> efficiency, or can this line in LzNode,
>>>>>
>>>>> var options = null;
>>>>>
>>>>> be changed to,
>>>>>
>>>>> var options = {};
>>>>>
>>>>> Many variables in the lfc are initialized to null. I wonder if
>>>>> this will
>>>>> become a common theme as the components are brought up.
>>>>>
>>>>> I changed it on my machine and was able to get much further, until
>>>>> the app
>>>>> hit another issue.
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>> They're all in! Try the window example - it seems to fail in a
>>>>> similar
>>>>>> way...
>>>>>>
>>>>>> -Max
>>>>>>
>>>>>> Henry Minsky wrote:
>>>>>>> Did you check those resources in? I can try and see what bug is
>>>>>>> halting
>>>>>>> the interpereter.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
