So why does the object-valued-attributes-get-magically-merged loop
not cover this case? Does this loop actually work? What attributes
is it expected to work on? Hm. I see there are two instances of
this loop, one in LzNode and one in LzUserClass. In the latter, you
only enter that loop if there is a setter associated with the
attribute. But, if there is a setter associated with that attribute,
why does the setter not just handle this magic merge?
In Legal's, we explicitly ensure that the dictionaries: setters,
getters, defaultattrs, __LZdelayedSetters, and earlySetters are
inherited from the superclass using a private dictionary (so the
subclass won't clobber the superclass's dictionary). And, if an
instance defines a setter, we ensure that it makes a private
dictionary first. But this is not the case for these other inherited
dictionaries. I guess getters aren't really used any more, and these
other things are internal-only so instances would not be adding to
them? It seems to me that options should be handled just as setters
are.
And perhaps the object-valued-attributes-get-magically-merged loop
should be retired, since it does not seem to really do what we expect?
Or maybe you could explain to me what is really supposed to happen
here? I'm having a hard time figuring out what the semantics are
supposed to be just from unwinding the code...
On 2006-09-26, at 03:07 EDT, Adam Wolff wrote:
> You're not confused. It doesn't work as designed. This line in trunk
> LzNode is just wrong:
>
> LzNode.prototype.setOption = function ( key , val ){
> if ( !this.options ) this.options = {};
>
> That's makes it break on instances. And it doesn't work in a case like
> this:
> <class name="a" options="x : 1"/>
> <class name="b" options="y : 1" extends="a"/>
>
> Because there's no setter for options. So yeah, it was busted before.
> A
>
>
> On Sep 25, P T Withington wrote:
>
>> From what I understand you to say, I should expect node options to be
>> inherited. But this test case fails in trunk. Am I confused, or
>> are options
>> completely broken?
>>
>> <canvas debug="true">
>> <include href="lzunit" />
>> <class name="top" options="some: 'thing'" />
>> <class name="middle" extends="top" options="other: 'else'" />
>> <class name="bottom" extends="middle" options="besides: 'what'" />
>> <middle id="m1">
>> <bottom id="b1" options="last: 'end'">
>> </bottom>
>> </middle>
>>
>> <class name="Options" extends="TestCase">
>> <method name="testOptions">
>> <![CDATA[
>> assertEquals('thing', b1.options['some']);
>> assertEquals('else', b1.options['other']);
>> assertEquals('what', b1.options['besides']);
>> assertEquals('end', b1.options['last']);
>> b1.setOption('other', 'another');
>> assertEquals('else', m1.options['other']);
>> ]]>
>> </method>
>> </class>
>>
>> <TestSuite>
>> <Options />
>> </TestSuite>
>> </canvas>
>>
>>
>>
>> On 2006-09-21, at 18:52 EDT, Adam Wolff wrote:
>>
>>> This looks good. Is there a test to make sure that instances get
>>> their
>>> class and superclass options? What about replicated views not
>>> sharing a
>>> single options slot? The code looks correct, but those would be
>>> nice to
>>> have.
>>>
>>> If there is strict enforcement of getter/setter-only access to
>>> options,
>>> then maybe this would be a good time to rename the options slot to
>>> __LZoptions, especially since writing to that slot would be
>>> catastrophic.
>>>
>>> A
>>>
>>> On Sep 21, P T Withington wrote:
>>>
>>>> And just let me know if it seems like the right solution? It's
>>>> a little
>>>> tricky, so I didn't want to check it in without a sanity check...
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: P T Withington <[EMAIL PROTECTED]>
>>>>> Date: 18 September 2006 15:09:06 EDT
>>>>> To: Adam Wolff <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>>>>> Cc: [email protected]
>>>>> Subject: For Review: Change change.zpAulUWBZ.txt Summary: Make
>>>>> node
>>>>> options
>>>>> type safe
>>>>>
>>>>> Change change.zpAulUWBZ.txt by [EMAIL PROTECTED]
>>>>> /Users/ptw/pending-changes/ on 2006-09-18 13:07:00 EDT
>>>>>
>>>>> Summary: Make node options type safe
>>>>>
>>>>> Technical Reviewer: adam (pending)
>>>>> QA Reviewer: henry (pending)
>>>>> Doc Reviewer: (pending)
>>>>>
>>>>> Details:
>>>>> Use a sentinel hash for options. Replace the sentinel in the
>>>>> setter.
>>>>>
>>>>> Tests:
>>>>> Inspection
>>>>>
>>>>> Files:
>>>>> M core/LzNode.lzs
>>>>
>>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
