No I cannot confirm this. This is a general issue with JavaScript (reference types). As there is no support for some deep copy to handle situations like this. The suggested work-around is to move this default to the constructor and apply it there. To update a property value through the getter is normally a quite unsupported behavior. What's about to simply split up the property in two or more properties if this would solve this. Generally this is, as mentioned before, not a issue with the property system. It could also not solved with some deferring. The real issue is the misunderstanding of reference types I think.
Regards, Sebastian Am 27.03.2007 um 18:34 schrieb [EMAIL PROTECTED]: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- 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
