[Proxies] Refactoring prototype climbing in the spec
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:
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss