[Laszlo-user] proposal for new behavior of compiler when declaring child nodes with same name as attributes

[jamesr]

I have the same issues in a project I was working in but tried to  
solve it by having subspaces so that, say, the View->Box->Window  
inherited class chain have their attributes in the View.x, Box.x, and  
Window.x namespaces.

That wasn't too smooth for compositional uses and i hadn't proceeded  
further. Since it doesn't happen all that much, you're right, i like  
what you've done.  Thanks for taking the time to write it out for us.

-james


On Jun 2, 2008, at 11:21 AM, P T Withington wrote:

> Surely you want to be warned if you are tromping on one of the  
> attributes of your superclass?
>
> LZX has always only had one namespace.  But it used to have 3  
> separate lists of 'initial arguments' to constructors:
>
> 1) simple initial values
> 2) constraints
> 3) styles
>
> even though these different initial values were all specified in the  
> same place in an attribute.
>
> This was an unending source of bugs, because people were constantly  
> discovering that when they subclassed a class, overriding an initial  
> argument of one kind with another kind never worked the way you  
> expected.  (E.g., if your superclass constrained an attribute and  
> you tried to set it to a constant, your superclass would win!  The  
> work-around was for you to constrain the value in your subclass to a  
> constant value.)  And each of these lists was treated differently  
> when they supplied an initial value for an attribute that had a  
> setter!
>
> Now we have a single initial arguments list, and overriding works as  
> expected.  But also, the processing of values for attributes with  
> setters is uniform.  This should be a good thing, but revealed a  
> gray area in the language.  What did it mean to have a child node  
> with the same name as an attribute?  What if that attribute has a  
> setter?  Or is processed specially by the class construct method?
>
> To Henry and I, it seems like trying to use the same name for an  
> attribute and a child node ought to be an error.  But, if you  
> _really_ want this, we give you an out.  You can declare your  
> attribute to be of type node, and when the child is created, it will  
> be stored in the attribute (using the setter if there is one).
>
> On 2008-06-02, at 10:25 EDT, jamesr wrote:
>
>> It's not that I disagree with the proposal, but in a way I mourn  
>> the passing of simpler namespacing. It seems like the orthgonal  
>> namespaces increase complexity of the run time, and part of me  
>> wants to see that complexity managed by framework authors - i.e.  
>> using prefixed names for reserved words so that layout becomes  
>> lzLayout. It's not that the proposal is bad from a CS standpoint,  
>> but that it steepens the learning curve of how laszlo works. It  
>> seems to me that telling people that what names you see from  
>> inspecting a node is what populates your namespace (like a typical  
>> object), not that some conflict and some don't based on an  
>> implementation you don't see.
>>
>> However this is just philosophy and not pragmatism. If this  
>> proposed feature works stably and doesn't cause problems, it's hard  
>> to argue against it.
>>
>> -j
>>
>> On Jun 2, 2008, at 8:38 AM, P T Withington wrote:
>>
>>> I think this is a good proposal, since it should actually be  
>>> pretty rare that you want to declare an attribute that ends up  
>>> being one of your child nodes.
>>>
>>> On 2008-05-28, at 13:24 EDT, Henry Minsky wrote
>>>
>>>> Sorry my message got cut off before I could finish it:
>>>>
>>>> This is a proposal in response to this bug, which came up when  
>>>> someone named
>>>> a child view "layout", and got
>>>> unexpected results in a view.
>>>>
>>>> http://jira.openlaszlo.org/jira/browse/LPP-5799
>>>>
>>>> The current compiler behavior is that it will allow you to  
>>>> declare a child
>>>> with the same name as an attribute,
>>>> as long as the attribute has a null default value. This  
>>>> unfortunately
>>>> applies to virtually every attribute
>>>> declared in the schema, so in practice you can easily shadow all  
>>>> sorts of
>>>> important properties in
>>>> a view or node, by naming a child view with the same name as a  
>>>> class
>>>> attribute, with no warning from the compiler.
>>>>
>>>> This proposal is that we add a new LZX attribute type, "node",  
>>>> which you can
>>>> use to declare that
>>>> an attribute name can have the same name as child node.
>>>>
>>>> So for example you could have
>>>>
>>>> <class name="myclass">
>>>> <attribute name="titleview" type="node"/>
>>>>
>>>> <handler name="oninit">
>>>>    this.titleview.setAttribute('bgcolor', 0xcccccc);
>>>> </handler>
>>>> </class>
>>>>
>>>> Then elsewhere you could say
>>>>
>>>> <myclass>
>>>>  <view name="titleview">
>>>>    ....
>>>> </myclass>
>>>>
>>>> And the compiler would not complain.
>>>>
>>>> The existing compiler  behavior would be changed so that for any  
>>>> attribute
>>>> type
>>>> except "node",  if you name a child node
>>>> with the same name as that  attribute, you get a compiler warning,
>>>> regardless of
>>>> whether the attribute was declared with a default value.
>>>>
>>>>
>>>>
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky at laszlosystems.com
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-user/attachments/20080602/244ed758/attachment.html