Property descriptor normalization (Was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

Tom Van Cutsem at
Fri Jan 4 00:05:09 PST 2013

2013/1/3 Allen Wirfs-Brock <allen at>

> On Jan 3, 2013, at 12:18 AM, Tom Van Cutsem wrote:
> I think it's perfectly obvious what it means for an exotic property to be
> complete: that it is at least a complete data or accessor property (i.e. it
> either has {value,writable,enumerable,configurable}, or it has
> {get,set,enumerable,configurable} properties). It may further specify any
> number of additional custom attributes.
> You seem to be assuming that all exotic properties must be an incremental
> variation of a data property or an accessor property.  However,
> historically this hasn't been the case.  When accessor attributes were
> added to ES they weren't just a incremental extension to the attributes of
> a data property. If any new property forms are added to ES in the future,
> they probably also won't be simply extended variations of data or accessor
> properties.  I would hope that proxies could be used to prototype any such
> future extensions.
> As part of a general extension mechanism, I don't think we should
> unnecessarily limit how a proxy handler chooses to define the
> interpretation of its property descriptors.  It's clear to me that such
> limitations restrict the utility of proxies.  What benefit to we get from
> those limitations.
> More generally, I think it is backwards-compatible to extend property
> descriptors with extra attributes, but it's backwards-incompatible to allow
> proxies to remove some of the standard attributes from property
> descriptors. This breaks the assumptions of existing clients.
> Since we never fully defined the invariants of
> Object.getOwnPropertyDescriptor it isn't clear what assumptions existing
> clients should be making.  I think the most basic assumption that is
> justified is that the result of gOPD can be used with Object.defineProperty
> to define a similar property on a different object that is the *same kind*of object as the original.

Thanks, I feel this conversation has brought us to a higher-level point
that I hope will allow others to join in.

Your position is that ES5.1's property descriptors are really open-ended
sets of attributes, and ES5.1 clients should not assume that the result of
Object.getOwnPropertyDescriptor is either a data or an accessor property.
It may return some third type of non-standard property.

My position is that ES5.1, by codifying only two kinds of property
descriptors, effectively does allow clients of
Object.getOwnPropertyDescriptor to assume that the result is either a data
or an accessor property. And my position is also that there most likely
exists ES5.1 code that builds on this assumption. I also don't know of any
DOM or other host objects that return a third type of property.

>From your point of view, it's only natural that proxies would be an ES6
programmer's tool to define and experiment with entirely new types of

>From my point of view, it's problematic (as in: not backwards-compatible)
that ES6+ would expose any new type of property via existing APIs at all
(with proxies or even just directly in the spec itself).

We will need some agreement on this higher-level point before we can make
good decisions at the level of the Proxy API.

What do others think?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list