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
