yes. again the loop at the top of LzNode handles this now.
A
On Sep 18, P T Withington wrote:
> Question:
>
> Is it expected that I could have default options on a class and then my
> subclasses should inherit those options?
>
> On 2006-09-18, at 10:55 EDT, Adam Wolff wrote:
>
> > Don't know if this was already discussed, but my preference would be to
> > put an empty hash on the LzNode prototype. Then setOption could test for
> > it and initialize the slot with a new hash before setting only if
> > this.options == LzNode.prototype.options. Most nodes don't have options,
> > so it's really a waste to give an empty hash to each one.
> >
> > A
> >
> > On Sep 18, Henry Minsky wrote:
> >
> > > Did we ever put in a patch for this?
> > >
> > > The simplest one would be
> > >
> > > var options = {};
> > >
> > > in LzNode.lzs I guess.
> > >
> > > The other alternative would be to rewrite the callers to use getOption() ,
> > > which checks for null, instead of
> > > directly accessing the options slot, but that would cost a function
> > > call...
> > >
> > >
> > > On 9/15/06, P T Withington <[EMAIL PROTECTED]> wrote:
> > > >
> > > > One work-around is to initialize the options slot in the initialize
> > > > method of the class LzNode, that will ensure that each instance has
> > > > it's own hash. There is a possibility that could be an efficiency
> > > > issue if most nodes don't have options.
> > > >
> > > >
> > > > On 2006-09-15, at 10:51 EDT, Henry Minsky wrote:
> > > >
> > > > > I would just be careful about making sure that the object which is
> > > > > created
> > > > > is not shared among multiple instances; in other words
> > > > > the initializer for the instance needs to make a new object.
> > > > >
> > > > > We had an issue like this with the subnodes or subviews array early
> > > > > on, I
> > > > > forget how we solved it, I am remembering something
> > > > > about how the accessor
> > > > > method for adding child views checked if it was an empty array ,
> > > > > and if it
> > > > > was trying to add an entry to the empty array, it created a new
> > > > > array. So
> > > > > the default empty array was shared among all instances of view but
> > > > > a fresh
> > > > > object was consed up the first time it was needed.
> > > > >
> > > > >
> > > > >
> > > > > On 9/15/06, Philip Romanik <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Henry,
> > > > > >
> > > > > > I started looking at his a little bit at this issue. I bypassed the
> > > > > > initial
> > > > > > error and ran into something else. The component code expects that
> > > > > > the
> > > > > > options property to be non-null.
> > > > > >
> > > > > > For example, in basewindow.lzx:
> > > > > >
> > > > > > <method name="construct" args="parent,args">
> > > > > > var wlist = parent.options['windowlist'];
> > > > > > if (wlist == null || typeof wlist == "undefined") {
> > > > > > wlist = [];
> > > > > > parent.setOption('windowlist', wlist);
> > > > > > }
> > > > > > super.construct(parent,args);
> > > > > > </method>
> > > > > >
> > > > > >
> > > > > > this is failing because parent.options is null. In LzNode.lzs,
> > > > > > options is
> > > > > > null until someone calls setOption() for the first time. Is this an
> > > > > > efficiency, or can this line in LzNode,
> > > > > >
> > > > > > var options = null;
> > > > > >
> > > > > > be changed to,
> > > > > >
> > > > > > var options = {};
> > > > > >
> > > > > > Many variables in the lfc are initialized to null. I wonder if
> > > > > > this will
> > > > > > become a common theme as the components are brought up.
> > > > > >
> > > > > > I changed it on my machine and was able to get much further, until
> > > > > > the app
> > > > > > hit another issue.
> > > > > >
> > > > > > Phil
> > > > > >
> > > > > >
> > > > > > > They're all in! Try the window example - it seems to fail in a
> > > > > > similar
> > > > > > > way...
> > > > > > >
> > > > > > > -Max
> > > > > > >
> > > > > > > Henry Minsky wrote:
> > > > > > > > Did you check those resources in? I can try and see what bug is
> > > > > > > > halting
> > > > > > > > the interpereter.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Henry Minsky
> > > > > Software Architect
> > > > > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > >
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
