I think this predates that change, but I'll check the 'publish' flag logic On Tue, Nov 24, 2009 at 6:43 PM, P T Withington <[email protected]> wrote:
> 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] > > -- Henry Minsky Software Architect [email protected]
