Object.getOwnPropertyDescriptor can return just about anything

Tom Van Cutsem tomvc.be at gmail.com
Thu May 8 14:23:15 PDT 2014


Allen, Mark and I discussed the [[Origin]] issue and came to the following
consensus:

We remove [[Origin]] and revert to the originally specified behavior (<
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec>) where the
descriptor returned by the proxy is coerced into a fresh, normalized,
completed, ordinary descriptor object.

This ensures complete backward-compatibility with the ES5 behavior (i.e.
Object.getOwnPropertyDescriptor will always return a fresh, complete data
or accessor descriptor), and doesn't allow a proxy to play tricks with
descriptor objects.

Allen's remaining concern is that this disallows proxies (or new exotic
objects) from inventing new types of descriptors, next to data and accessor
descriptors. Due to backwards-compat. constraints, we're basically stuck
with these two types of property descriptors forever.

The originally specified Proxy behavior also included copying any
non-standard attributes provided by the proxy onto the fresh descriptor
object. However, if we're serious about keeping
Object.getOwnPropertyDescriptor backwards-compatible with existing ES5
code, we may be better off by not augmenting descriptor objects with
non-standard attributes, even if this is unlikely to break existing code.
As Jason mentioned, if proxies want to introduce new per-property
attributes, they can provide other means of getting at that meta-data
rather than abusing the standard reflection API.

So, the current proposal is to spec [[GetOwnProperty]] for Proxies such
that the descriptor returned by the trap is coerced into a fresh,
normalized, complete descriptor object, without copying custom attributes.

Relevant bug seems to already have been filed by Andre: <
https://bugs.ecmascript.org/show_bug.cgi?id=2382>

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140508/027e730e/attachment.html>


More information about the es-discuss mailing list