Yeah, I only envision this being used in a specific case, where you have
some class
that expects to have a certain named child or children, but those children
aren't
specified in the class, they are only supplied when a call to create an
instance of the
class is used. Like for example
<class name="upside_down_frame">
<!-- expects a named child named "content", and turns it upside down -->
<handler name="oninit">
this.content.setAttribute('rotation', 180);
</handler>
</class>
<upside_down_frame>
<view name="content"> ....
<view ...>
...
</upside_down_frame>
So in that case, the "content" var must be declared somehow to get the class
to compile under swf9, so you'd say
<attribute name="content" type="node"/>
in the class declaration.
Aside from this use case, the common case will now be that if you
inadvertently shadow a declared
attribute with a named child, you'll get a compiler warning, which should
hopefully prevent hard-to-find bugs
from happening.
On Mon, Jun 2, 2008 at 11:21 AM, P T Withington <[EMAIL PROTECTED]> 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
>>>> [EMAIL PROTECTED]
>>>>
>>>
>>>
>>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
