[Proxies] Refactoring prototype climbing in the spec

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 8 09:56:20 PST 2011

This is all going in a good direction.

I only have a few minor comments:

I don't think that [[GetP]] and [[PutP]] need to be "internal methods"
In spec'ing this I think I would make them be "abstract operations". Internal methods are extensions points that can be over-ridden on a per object basis.  That is what [[Get]] and [[Put]] provides.  GetP and SetP define fixed operations.

More generally, I think there should be a 1::1 correspondence between the internal methods in listed in ES5 Table 8 and fundamental proxy traps. We either need to eliminate any internal methods that don't trap or add corresponding traps.  In this proposal you eliminate the need for [[CanPUt]] and you raise the question of whether that is possible for also get rid of [[GetProperty]].  My analysis (https://docs.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdDFkcy1VUl9OQ3BSc1kxeDI4RkJsc0E ) says that we can, so we should just go ahead and eliminate it. 

We might even consider eliminating [[Delete]] by defining [[DefneOwnProperty]](name,undefined) to mean delete. 

Finally, I also have some thoughts about [[HasProperty]] but I will put those in a replay to Andreas message on that touches on that.


On Nov 7, 2011, at 7:54 AM, Tom Van Cutsem wrote:

> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111108/a2f768dd/attachment.html>

More information about the es-discuss mailing list