Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)
Tom Van Cutsem
tomvc.be at gmail.com
Fri Nov 2 01:33:06 PDT 2012
2012/11/1 David Bruant <bruant.d at gmail.com>
> Currently, TrapGetOwnProperty returns an object, but when there is an
> actual trap, it goes through:
> * NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6)
> * ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step 3 of
> * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
> We might as well get rid of the spec-only PropertyDescriptor, define an
> equivalently pre-condition/invariant enforcing ES5 construct and
> manipulate that both internally and in trap boundaries.
I think the deal-breaker, as Allen pointed out, is that what you call an
ESUsablePropDesc would still need to be mutable (if it wants to mimic
Plus, it doesn't get rid of the implicit conversions at proxy
boundaries. In the case of defineProperty you'd still have to convert
between a plain object passed in as 3rd arg, and an ESUsablePropDesc. In
the case of getOwnPropertyDescriptor, to preserve current semantics, you
must still copy the (mutable) ESUsablePropDesc to ensure that all calls to
getOwnPropertyDescriptor return fresh, independent objects.
Granted, having an ESUsablePropDesc would avoid conversions in the case of
proxies forwarding the operation to their target.
Thanks for drawing my attention to the auxiliary functions: it made me
realize that Aux.3 NormalizePropertyDescriptor and Aux
4. NormalizeAndCompletePropertyDescriptor are only called in one place. I
think that by in-lining their definitions we might get rid of some
That said, the "redundancy" you point out, i.e. the conversion from Object
-> PropDesc immediately followed by PropDesc -> Object is not really
redundant: it's needed to "normalize" the descriptor. Implementations can
probably optimize so that they don't actually have to allocate an
intermediate internal property descriptor, but immediately create an Object
> The way I see it now, ESUsablePropDesc would be a regular object with a
> bunch of getter/setters to enforce property descriptor invariants.
> Everything would remain compatible (unless people really cared that ES5
> descriptors have data properties).
Unfortunately it's not a question of caring: currently, an ES5 meta-program
can make the valid assumption that all "standard" attributes of a property
descriptor object are data properties. Changing this assumption is not
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss