<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>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.</div><div><br></div><div>-james</div><div><div><div><br></div><div><br><div><div>On Jun 2, 2008, at 11:21 AM, P T Withington wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Surely you want to be warned if you are tromping on one of the attributes of your superclass?<br><br>LZX has always only had one namespace. But it used to have 3 separate lists of 'initial arguments' to constructors:<br><br>1) simple initial values<br>2) constraints<br>3) styles<br><br>even though these different initial values were all specified in the same place in an attribute.<br><br>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!<br><br>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?<br><br>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).<br><br>On 2008-06-02, at 10:25 EDT, jamesr wrote:<br><br><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-j<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Jun 2, 2008, at 8:38 AM, P T Withington wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 2008-05-28, at 13:24 EDT, Henry Minsky wrote<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Sorry my message got cut off before I could finish it:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This is a proposal in response to this bug, which came up when someone named<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a child view "layout", and got<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">unexpected results in a view.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://jira.openlaszlo.org/jira/browse/LPP-5799">http://jira.openlaszlo.org/jira/browse/LPP-5799</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The current compiler behavior is that it will allow you to declare a child<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">with the same name as an attribute,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">as long as the attribute has a null default value. This unfortunately<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">applies to virtually every attribute<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">declared in the schema, so in practice you can easily shadow all sorts of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">important properties in<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a view or node, by naming a child view with the same name as a class<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">attribute, with no warning from the compiler.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This proposal is that we add a new LZX attribute type, "node", which you can<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">use to declare that<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">an attribute name can have the same name as child node.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So for example you could have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><class name="myclass"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><attribute name="titleview" type="node"/><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><handler name="oninit"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> this.titleview.setAttribute('bgcolor', 0xcccccc);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"></handler><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"></class><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Then elsewhere you could say<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><myclass><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> <view name="titleview"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> ....<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </myclass><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">And the compiler would not complain.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The existing compiler behavior would be changed so that for any attribute<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">type<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">except "node", if you name a child node<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">with the same name as that attribute, you get a compiler warning,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">regardless of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">whether the attribute was declared with a default value.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Henry Minsky<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Software Architect<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></div></div></div></body></html>