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]
