If we did use LzInheritedHash, when would we retrieve the unmasked version
for each class? We'd need the new class initializer too, right?
On Sep 2, P T Withington wrote:
> On 2006-09-02, at 18:37 EDT, Adam Wolff wrote:
>
> > I think we're saying the same thing. FWIW $path expressions are passed as
> > written -- with or without quotes -- and the runtime parses them.
>
> We should consider doing them the way $style is done. Then you can have a
> general expression, and they would all be done at once.
>
> > I'd rather just implement proto smashing for now and fix it in legals
> > later, rather than port LzInheritedHash to coal.
>
> If you're pressed, fine. It will just make it harder to port CSS to Legal's.
> LzInheritedHash is trivial, BTW:
>
> //---
> // @keywords private
> // Used to efficiently clone hashtables using Object's
> // N.B. these tables incorrectly will appear to have entries for all
> // the properties of Object.prototype. To avoid this (but pay the
> // of a slower implementation, use LzDictionary).
> //---
> LzInheritedHash = {
> make: function make (parent) {
> if (parent) {
> function xtor() {};
> xtor.prototype = parent;
> return new xtor();
> }
> return new Object;
> }
> }
>
> > 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
