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. Allen 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
