On defining non-standard exotic objects
allen at wirfs-brock.com
Wed Jan 9 11:44:24 PST 2013
On Jan 9, 2013, at 7:24 AM, Brandon Benvie wrote:
> On Wed, Jan 9, 2013 at 9:07 AM, David Bruant <bruant.d at 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).
Except that the spec. is not describing a required implementation factoring, just required results. There is no particular reason that an implementation must have the same internal factoring as the spec. or that an implementation exposes via an implementation-specific extension mechanism the equivalent of the abstract operations used within the specification. So while, the spec. refactoring hopefully makes life easier for future spec. writers (including me) and for readers of the spec. I don't think it helps implementors to use object aspects in the way you seem to be envisioning.
On the other hand, the @@hooks are intentionally design to provide extension mechanisms that operate above the level of the MOP (internal methods) and its object invariants. As much as possible, I want to use that style of extension hook and avoid extending or complicating the MOP.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss