Hi Derrell!
[EMAIL PROTECTED] wrote:
> > The problem here is that the determination of default values of 'properties'
> > is not deferred until object instantiation; rather, the default value is
> > calculated in-line as the application is initially read/processed. This
> > means
> > that any property that has a default value that yields a reference rather
> > than
> > a value is actually sharing the property "value" (what the reference points
> > to) with all instantiations of the object. This could be a real problem if,
> > for example, one created a class with a property like this:
> >
> > uniqueValue :
> > {
> > _legacy : true,
> > defaultValue : new Array(23, 42)
> > }
> >
> > If there are two objects of this class and one of them does:
> >
> > var a = o.getUniqueValue();
> > a[1] = 69;
> >
> > then the other object will now see [ 23, 69 ] instead of its supposed
> > default
> > value of [ 23, 42 ]. This would be true of objects instantiated before or
> > after the defaultValue array was modified.
> >
> > I believe this is unexpected behavior, and as we're creating a new property
> > system at the moment, this is the time to allow/encourage default value
> > calculation to be deferred until object instantiation.
> >
> > I can see, BTW, uses for shared property references. We had previously
> > discussed the need for class-wide read/write/modify Settings since the new
> > Settings mechanism is read-only at run-time and doesn't allow, for example,
> > setting a debug levels within (all instances of) a class via user control
> > from
> > the gui. I could make use of this shared property to implement that, but
> > I think that's a real kludge!
> >
> > I'd like to see, in the new property implementation, default value
> > calculations deferred until object instantiation. Optionally, for the
> > purpose
> > of sharing properties (if this were to be a documented feature), a
> > "no_defer"
> > flag to indicate that the default value should be calculated at the time
> > that
> > the class is being read, as is currently done with Legacy properties.
> >
> > (If nothing else, then a warning should be generated if a property's default
> > value is an object, so that the unsuspecting user doesn't find himself with
> > shared objects. This, however, is much less ideal than the previous
> > solution.)
Unfortunately, I doubt there is a single optimal solution to this
behaviour. It is so fundamental to the JavaScript language itself...
Data types that are non-problematic as init values of properties are the
primitive types (Boolean, Number, String). Fortunately, this should be
true for most of qooxdoo's framework and application code. On the other
hand reference types work, as their name suggests, only as references to
complex JavaScript objects (Array, Object, etc.).
This language concept, and its potential problems, needs to be
understood by every qooxdoo user. Often, even experienced JS developers
make mistakes in this area, though. The problem is not limited to
declaring dynamic properties, though, both in legacy and proposed new
property implementation. Also both the legacy and new class declaration
are equally affected: e.g. assigning a reference type to an instance
member behaves similar to your description of the problem above.
For both
qx.Proto.prop1 = [23, 42]; // 0.6.x
and
members: { prop1: [23, 42] } // 0.7
two instances would not deal with their own, separate property, but they
would access and potentially alter a shared data structure.
Unfortunately, there is no practical way to defer such initializations
and bind them to individual instances. Any non-qooxdoo, plain JS code
exhibits the same potential problems.
As you suggested (as a last resort), this behavior must at least be made
very clear in the new documentation (even if it is the known behavior in
all existing qooxdoo versions).
Well, some good news: in our discussion of the new property
implementation we came up with a practical solution to avoid potentially
hazardous coding during development: there could be an additional key in
the property declaration map that indicates that the developer
explicitly is aware of and wants to have a complex (i.e. reference type)
init value (as said, something that should not be very common).
Your example code may read:
properties : {
uniqueValue : { init: [23, 42], shared: true }
}
Plz take "shared" just as a placeholder name here. If this optional
attribute is not given, but a complex init value, the source version of
a qooxdoo application (which, BTW, will provide much better development
support compared to the 0.6.x version) should give an error.
Tomorrow, we need to wrap up the discussion about the topic that we
actually had here a few days back. Take this as some first input. What
do you think so far?
Cheers,
Andreas
PS: As I am just thinking about the topic, maybe there is a practical
way to defer the init value assignment into the constructor. I'll send
you an update tomorrow...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
