Sebastian, you didn't comment on this. Can you confirm that the new property system will solve this problem?
Thanks, Derrell [EMAIL PROTECTED] writes: > dperez <[EMAIL PROTECTED]> writes: > >> Hi Derrell, >> >> Here is a simple sample that demostrates clearly the bug: >> http://www.nabble.com/file/7282/TreeVirtual_5.html TreeVirtual_5.html >> >> It could be kept as a test. >> >> Uncomment line 88 to see how the table affects the tree. >> if (0) --> if (1) >> >> There must be some singleton. I have reviewed the code, but haven't >> located. :-( > > Your evaluation is spot-on. This is fixed in rev 6938. Thanks! > > 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.) > > Derrell ------------------------------------------------------------------------- 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 qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
