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
