That's a bug then. Perhaps this has the same root as the regression you just fixed?
Nothing should go in lz unless it is really defining a tag. On 2009-11-24, at 18:23, Henry Minsky wrote: > Hmm, now that you mention it, I notice we've been adding the interstitial > class names that come from compiling class mixins to the lz namespace > object: > > lz["colored_square$view"] = $lzc$class_colored_square$view; > lz["black_line$colored_square$view"] = > $lzc$class_black_line$colored_square$view; > > > I don't think we need them in there, do we? The compiler seems to be > emitting > calls to instantiate the objects directly using the classname when it calls > LzInstantiateView e.g., > > "class": $lzc$class_black_line$colored_square$view > > > > > > > On Tue, Nov 24, 2009 at 5:36 PM, P T Withington <[email protected]> wrote: > >> On 2009-11-24, at 17:01, Rami Ojares / AMG Oy wrote: >> >>> Hi, >>> >>> Current documentation has this to say about node's createChildren(carr) >> argument >>> >>> "an array of children where the structure of each child [c] takes the >> form: >>> c.name = a string containing the name of the child -- usually its >> constructor >>> c.args = a dictionary of attributes and values to be passed to the >> constructor of that child >>> c.children = an array of children for the new child" >> >> You are venturing into things that most people don't, since they just use >> the XML language for their applications. >> >> I think the documentation on makeChild is more accurate. createChildren is >> really just a hook to allow a subclass to change where and when it actually >> makes its children. makeChild is the interface that actually interprets the >> children specification. (Don't blame me for the confusing names, I did not >> make them up!) >> >> c.name is still valid, it is used to make a child be of the class that >> implements a particular tag (so you say 'view' to get a <view>, etc. You >> can use this to make any node that has a tag). >> >> c.class is an optimization, used by the compiler to: >> >> 1) Avoid having to look up the name >> 2) Instantiate 'instance classes' >> >>> None of this seems to be true. >>> Instead the children seems to have the structure: >>> c.attrs = a dictionary of attributes and values to be passed to the >> constructor of that child >>> c.class = pointer to the class to be instantiated >>> >>> When you further inspect the class there is one useful attribute: >>> tagname. That seems to have the same function as c.name in the above >> mentioned documentation. >>> >>> Further it seems that in the current trunk if you instantiate a class >> with a constrained attribute like this >>> >>> <view height="${foo.height}"/> >>> >>> It's tagname becomes >>> "anonymous tagname" >> >> Right. This is a so-called "instance class". In order to have a >> constraint, an instance needs some supporting methods. (You would see the >> same thing if you gave your instance an explicit <method>.) In order to >> have methods, the compiler has to build a class, and then make just one >> instance of that class. It doesn't define a tag for that class, because it >> will only ever be made by the compiler (or by replication, which works >> automatically). The tagname in this case, is just for debugging. If you >> were to look at the non-debug version, you would see the tagname is not >> emitted. And of course, the class is _not_ entered into `lz` (as are all >> real class definitions, e.g., lz['view'] => the class that implements >> <view>, so lz[<any tag name>].tagname == <any tag name>, but not for >> 'anonymous' or 'instance' classes.) >> >>> Code: >>> >>> <canvas debug="true"> >>> <view > >>> <method name="createChildren" args="children"><![CDATA[ >>> for(var i=0; i<children.length; i++) { >>> Debug.write(children[i]['class'].tagname); >>> } >>> ]]></method> >>> <view height="${canvas.height}"/> >>> <view/> >>> </view> >>> </canvas> >>> >>> Produces the output in debug window: >>> anonymous view >>> view >>> >>> Is this how it is supposed to be? >> >> That's how it is supposed to be. :) >> >>> Or is this an accident caused by the instance specific mixin development? >> >> Although, we did just add this feature to make it easier to debug instance >> mixin's. Before, we never emitted a tagname for "instance classes". But we >> decided it would help debugging to give them a tagname that told what tag >> they were derived from. >> >> >> > > > -- > Henry Minsky > Software Architect > [email protected]
