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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111107/0f45621b/attachment.html>