[Laszlo-dev] optimiziation for inheriting fontsize/name properties

[P T Withington]

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
>