Hi, I wrote up an initial (but fairly complete) draft of a proposed refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way in which these algorithms climb the prototype chain: < http://wiki.ecmascript.org/doku.php?id=strawman:refactoring_put>
This is mainly beneficial for proxies, as the prototype walking strategy becomes observable to proxies-used-as-prototypes. IMHO, the refactored algorithms interoperate with proxies in a much saner way, finally restoring the intuitive semantics of the "get" and "set" traps that MarkM and I had in mind from the beginning, but which Sean Eagan pointed out were flawed given the ES5 spec algorithms. The biggest change is in the [[Put]] algorithm. For those not into ES spec language, I wrote up the behavior for ES5 [[Put]] and my proposed ES.next [[Put]] in JS itself: ES5 [[Put]]: < http://code.google.com/p/es-lab/source/browse/trunk/src/es5adapt/setProperty.js#115 > Proposed ES.next [[Put]]: < http://code.google.com/p/es-lab/source/browse/trunk/src/es5adapt/setProperty.js#68 > The refactored version also fixes the anomalies resulting from the ES5 [[CanPut]] vs. [[Put]] split that Andreas Rossberg pointed out earlier on this list. When I say "refactoring" here, I really do intend for these new algorithms to be equivalent to the ES5 algorithms for non-proxy objects. To test whether these algorithms are indeed equivalent, I wrote up a little test-suite that runs in the browser: < http://es-lab.googlecode.com/svn/trunk/src/es5adapt/testSetProperty.html> The results look promising (success on Firefox7, 1 failure on Chrome/Safari because these allow overriding of non-writable inherited data props, haven't tested other browsers yet). Still, the more es-discuss eye-balls that can scrutinize these algorithms, the better. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
