But it wouldn't if we are not careful about how we handle the
sentinel... So I will be careful.
I am sure this loop will bite us some day. What if a user wanted to
have a class with an attribute that is a hash and _override_ that
hash in a subclass?
On 2006-09-18, at 14:16 EDT, Adam Wolff wrote:
> yes. again the loop at the top of LzNode handles this now.
>
> A
>
> On Sep 18, P T Withington wrote:
>
>> 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
