Hum. Well, I would have expected interstitials to create themselves as anonymous classes. Maybe I missed that.
On 2009-11-24, at 19:27, Henry Minsky wrote: > 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]
