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

P T Withington ptw at pobox.com
Mon Jun 2 08:21:39 PDT 2008

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

More information about the Laszlo-user mailing list