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
[EMAIL PROTECTED]
