That looks a lot like a cloning operation:
function cloneObject(obj) {
var clone = {};
for(var n in obj) {
clone[n] = obj[n];
}
return clone;
}
>> use prototype-inheritance to give you memo-izing for nearly free.
By "for nearly free" do you mean "without performance overhead"?
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>>> [EMAIL PROTECTED]
>>>>> _______________________________________________
>>>>> Laszlo-dev mailing list
>>>>> [email protected]
>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [EMAIL PROTECTED]
>>
>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> [EMAIL PROTECTED]
>>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
