[Laszlo-dev] optimiziation for inheriting fontsize/name properties
P T Withington
ptw at openlaszlo.org
Sat Apr 1 18:39:11 EST 2006
On 2006-04-01 11:19 EST, Jim Grandy wrote:
> Clever indeed -- kudos to Tucker!
Aw, shucks. You and Neil give me too much credit. Adam uses this
technique all over the LFC. The only 'clever' bit was to realize
there was a way to set the prototype chain with straight Javascript
(rather than relying on access to the internal __proto__ field as is
done in the SWF kernel).
It really is just a standard feature of a prototype-based language.
I think that everyone is so brainwashed by class-based languages (the
C++/Java marketing borg) that they forget there are other models.
Even we try to tweak Javascript to fit the more conventional class-
based model. I'm always glad when Adam reminds me about features
that come from our prototype-basis, like being able to magically make
singleton instances without having to create a class.
> This would put the "cascade" in our style model with very little
> effort. Nice.
>
> Two questions to pursue: how different would this be from our
> current style feature? And: how different would this be from w3c
> css? I'm not sufficiently up to speed on either to be able to
> answer these questions without some research.
You mean the current compile-time CSS implementation? I think our
goal with our current implementation is to be closer to w3c CSS, and
this could help us get closer by providing cascading at runtime.
(Obviously, for the DHTML back-end we can use the browser
implementation of CSS and it will just be correct.)
It will mean a change from the current way we implement some
features, such as text font/size/style, since they are presently
individual attributes of text, not properties of a single style
attribute.
> jim
>
> On Mar 31, 2006, at 9:30 PM, Neil Mix wrote:
>
>> That's very clever. And I'm humbled -- you just taught me something
>> about JavaScript that I didn't previously know. This language slays
>> me -- after 4 years of it I still don't have it down. :/ Neat.
>>
>> On Mar 31, 2006, at 5:33 PM, P T Withington wrote:
>>
>>> On 2006-03-31 17:59 EST, Neil Mix wrote:
>>>
>>>> That looks a lot like a cloning operation:
>>>>
>>>> function cloneObject(obj) {
>>>> var clone = {};
>>>> for(var n in obj) {
>>>> clone[n] = obj[n];
>>>> }
>>>> return clone;
>>>> }
>>>
>>> Except the clone will not track changes in the object it was cloned
>>> from. By using the prototype chain, if a view inherits a style
>>> from its parent and the parent's style changes, the view would see
>>> it too. (Hm, but there would still need to be an event sent to
>>> tell the child view to notice the change...) [Note in my code I
>>> set the css object to have the parent object as it's prototype, and
>>> then set the local values from the init args into the local css,
>>> which will cause them to override any in the parent. If you want
>>> to dynamically revert an overridden style to inherit from the
>>> parent, you just delete it and the parent value will be exposed.]
>>>
>>>>>> use prototype-inheritance to give you memo-izing for nearly free.
>>>>
>>>> By "for nearly free" do you mean "without performance overhead"?
>>>
>>> I mean, the chasing up the immediateparent chain would be done in
>>> the runtime (presumably _much_ faster than could be done by a
>>> Javascript for loop).
>>>
>>>> On Mar 31, 2006, at 3:23 PM, P T Withington wrote:
>>>>
>>>>> I believe so. I'm thinking you do something like this:
>>>>>
>>>>> // How to make a new object with an existing object as its
>>>>> prototype
>>>>> // in standard Javascript
>>>>> function makeNewObjectWithAnotherObjectAsItsPrototype
>>>>> (anotherObject) {
>>>>> var xtor = function () {};
>>>>> xtor.prototype = anotherObject;
>>>>> return new xtor();
>>>>> }
>>>>>
>>>>> // Assuming the css attributes of a particular view are passed as
>>>>> a hash
>>>>> // named style: in initargs
>>>>> View.init = function (initargs) {
>>>>> var style = initargs['style'];
>>>>> var css = makeNewObjectWithAnotherObjectAsItsPrototype
>>>>> (immediateparent.css);
>>>>> for (var k in style) {
>>>>> css[k] = style[k];
>>>>> }
>>>>> this.css = css;
>>>>> }
>>>>>
>>>>> On 2006-03-31 16:01 EST, Henry Minsky wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/31/06, P T Withington <ptw at openlaszlo.org> wrote: I
>>>>>> agree. My
>>>>>> question was about whether these things were inherited
>>>>>> along the parent or immediateparent chain. Since you don't know
>>>>>> the
>>>>>> immediateparent at compile time, it would be impossible to
>>>>>> make any
>>>>>> compile-time optimization. Also, I'm suggesting that if you
>>>>>> break
>>>>>> these 'cascading' attributes out into separate objects, they
>>>>>> could
>>>>>> use prototype-inheritance to give you memo-izing for nearly free.
>>>>>>
>>>>>> Instead of putting the cascading attributes directly on the
>>>>>> view, put
>>>>>> them in an object/hash that can have a different inheritance
>>>>>> chain
>>>>>> (i.e., the one specified by immediate parent).
>>>>>>
>>>>>> 'zat making any sense?
>>>>>>
>>>>>>
>>>>>> Can we do that in IE JScript?
>>>>>>
>>>>>> On 2006-03-31 15:30 EST, Henry Minsky wrote:
>>>>>>
>>>>>>> We have some code that attempts to compute the font size/name/
>>>>>>> style
>>>>>>> attributes at compile time, which means it has to use a model of
>>>>>>> the default
>>>>>>> attribute values ofr classes, etc. That code is there in
>>>>>>> ViewCompiler to do
>>>>>>> that, and it works but is kind of baroque, so I was leaning
>>>>>>> towards
>>>>>>> removing it if there would be not a runtime performance
>>>>>>> impact ; it
>>>>>>> seems
>>>>>>> like optimizing the runtime to memoize the inherited font all
>>>>>>> along
>>>>>>> the
>>>>>>> parent chain would be step towards increasing the runtime
>>>>>>> efficiency, and
>>>>>>> thus making the compile-time calculations less neccessary.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/31/06, P T Withington <ptw at openlaszlo.org> wrote:
>>>>>>>>
>>>>>>>> a) Is the font really determined by the immediate (dynamic)
>>>>>>>> parent?
>>>>>>>> That's annoying because it means you can't compute it at
>>>>>>>> compile
>>>>>>>> time.
>>>>>>>>
>>>>>>>> b) If css properties like this _are_ determined by the
>>>>>>>> immediate
>>>>>>>> parent, then perhaps the props should all be stored in a
>>>>>> separate css
>>>>>>>> attribute and we could use proto-based inheritance to do the
>>>>>> lookup.
>>>>>>>> E.g., css would be an attribute of view that is a hash, and the
>>>>>>>> hash's __proto__ would be the immediate parent's css hash.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is that something which behaves like the DHTML CSS model
>>>>>>> (which we
>>>>>>> would
>>>>>>> want to use I would think).
>>>>>>>
>>>>>>> On 2006-03-31 09:41 EST, Henry Minsky wrote:
>>>>>>>>
>>>>>>>>> The text class calls
>>>>>>>>>
>>>>>>>>> this.fontname = this.searchParents
>>>>>>>>> ( "fontname" ).fontname;
>>>>>>>>>
>>>>>>>>> for font name/size/style properties
>>>>>>>>>
>>>>>>>>> searchParents is implemented as
>>>>>>>>>
>>>>>>>>> LzView.prototype.searchParents = function ( prop ){
>>>>>>>>> var sview = this;
>>>>>>>>> do{
>>>>>>>>> sview = sview.immediateparent;
>>>>>>>>> if (sview[ prop ] != null ){
>>>>>>>>> return sview;
>>>>>>>>> }
>>>>>>>>> }while ( sview != canvas );
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Would it be more efficient if the searchParents function
>>>>>>>>> set the
>>>>>>>>> properties
>>>>>>>>> all the way back down the parent
>>>>>>>>> chain when it found one, so that other calls wouldn't have to
>>>>>>>>> search up past
>>>>>>>>> their first parent? It seems like with the
>>>>>>>>> way the value is filled in now, that wouldn't change the
>>>>>>>>> behavior
>>>>>>>>> because in
>>>>>>>>> the current code the font style attributes which are null at
>>>>>>>>> runtime are
>>>>>>>>> found and cached on a text element, and then modifying the
>>>>>>>>> parent
>>>>>>>>> has no
>>>>>>>>> subsequent effect on the text font style. So caching the
>>>>>>>>> parent
>>>>>>>>> values as
>>>>>>>>> well wouldn't change things anyway.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Henry Minsky
>>>>>>>>> Software Architect
>>>>>>>>> hminsky at laszlosystems.com
>>>>>>>>> _______________________________________________
>>>>>>>>> Laszlo-dev mailing list
>>>>>>>>> Laszlo-dev at openlaszlo.org
>>>>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Henry Minsky
>>>>>>> Software Architect
>>>>>>> hminsky at laszlosystems.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> hminsky at laszlosystems.com
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Laszlo-dev mailing list
>>>>> Laszlo-dev at openlaszlo.org
>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>
>>>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
More information about the Laszlo-dev
mailing list