On defining non-standard exotic objects

Brandon Benvie brandon at brandonbenvie.com
Wed Jan 9 07:24:15 PST 2013

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

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130109/8b193862/attachment.html>

More information about the es-discuss mailing list