Re: optimiziation for inheriting fontsize/name properties

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
>>
>