On Wed, Jan 9, 2013 at 9:07 AM, David Bruant <bruan...@gmail.com> wrote:
> The current situation is that ES folks would like to impose some > restrictions on how the language can be extended, especially when it comes > to objects. To the possible extent (and it looks possible), the limits > would be the one set by what's possible by proxies. > Now, there are 2 choices: > 1) "do whatever you want within these boundaries defined in prose" > 2) "proxies are the most powerful extension mechanism at your disposal" > > The former requires people to read the spec carefully, become very > intimate with it. > ... They just have to fit in the box they are provided and subtleties are taken > care of by the box, by design of how the box is being designed. > > One point I could understand is that maybe script proxies will not > necessarily make a conveninent box for spec writers. If this is really an > issue, ECMAScript could define an intermediate proxy representation that > would be used to spec proxies and by other spec writers. The crux of the matter is that the ES5 spec doesn't really allow for aspect oriented use of the internal methods. The granularity provided is pretty much at the method level: if you want to reuse the core functionality of say [[DefineOwnProperty]] then you're basically committing to reimplementing the whole thing, or at best pre- or post- processing the input/output of the standard ones. Proxies allow for deferring to the spec implementation and letting it do the heavy lifting of ensuring the internal consistency that a finely polished object protocol provides, and then stepping in to make the (usually small) adjustments needed for the exotic functionality. Proxies are only desirable as a model for implementers because of a lack of other options provided by the spec. They are actually pretty poorly suited in many ways because they're intended use is for untrusted code. The last couple revisions of the ES6 spec directly address this problem in a much better way for implementers. The core functionality of the internal methods is being split out into separate abstract operations that can be composed with the additional exotic functionality an implementer wishes to add. The flexibility that Proxies provide can be attained without layering on the added complexity that describing something in terms of Proxies requires. Specifically, I'm referring to things like OrdinaryGetOwnProperty, OrdinaryDefineOwnProperty, ValidateAndApplyPropertyDescriptor, OrdinaryConstruct, OrdinaryCreateFromConstructor, OrdinaryHasInstance, .etc, as well as indexed delegated objects which is a reusable solution for the most common form of exotic object. Along with these methods are the various hooks that they expose to implementers so that, for some things, it's not even required to override an internal method at all (@@create, @@hasInstance being examples).
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
