I think we're saying the same thing. FWIW $path expressions are passed as
written -- with or without quotes -- and the runtime parses them.
I'd rather just implement proto smashing for now and fix it in legals
later, rather than port LzInheritedHash to coal.
A
On Sep 2, P T Withington wrote:
> On 2006-09-01, at 20:12 EDT, Adam Wolff wrote:
>
> > Hi Tucker,
> > Ben found a bug with using $style in a class definition. Given:
> > <class name="super" bgcolor="${ 'stylea1' }"/>
> > <class name="sub" extends="super" x="${ 'stylea2' }"/>
> >
> > An instance of sub doesn't get the styled value. In general, this kind of
> > thing is handled by passing the collected style attributes as an Object,
> > which are then attached to the superclass version of the same in the ugly
> > loop at the top of the LzNode constructor. Since right now, the $style
> > attribute is a function, this object composition isn't happening.
> >
> > Thoughts? Feelings? Seems like the easiest thing to do would be to pass
> > $styles as a hash.
>
> Yes that magic object-merging loop is truly ugly, and I wouldn't be surprised
> if it bites us some day...
>
> $styles is a function so that $style constraints can be an expression.
>
> (Someday, it would be nice if the other constraints could be handled this way
> too, rather than the way path expressions are evaluated (only can be variables
> or member references), or the way once constraints have to be passed as
> individual functions.)
>
> I think the right way to handle this is the same way that setters are handled.
> In 3.x that means smashing the __proto__ of the hash to inherit from the
> superclass. In 4.x, where we can't do __proto__ smashing, we either have to
> copy the hash or pass in an empy LzInheritedHash to $styles to fill in. If we
> want to be forward-looking, perhaps we should do the latter in both cases?
>
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
