Property Descriptors as script compatible representation

David Bruant bruant.d at gmail.com
Fri Nov 2 03:22:32 PDT 2012


Le 02/11/2012 09:33, Tom Van Cutsem a écrit :
> 2012/11/1 David Bruant <bruant.d at gmail.com <mailto: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
>     NormalizeAndCompletePropertyDescriptor)
>     * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
>     NormalizeAndCompletePropertyDescriptor)
>
>     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 current property-descriptors-as-objects-with-some-invariants).
Since the mutability would be limited by invariant enforcement, I don't
think it would be a problem. Maybe this problem is bigger than I see it?

> 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.
Arguably, if there is a construct that represent property descriptors,
it may no longer be necessary to return a fresh object each time.

> 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 redundant conversions.
>
> 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.
No. What's needed is an algorithm to normalize the descriptor. The
conversion is just a convenience to reuse the spec algorithm. The other
alternative would be to duplicate the logic to make it applicable to
ECMAScript objects.
I'm not satisfied with any of these choices (but apparently I'm the only
one)

> Implementations can probably optimize so that they don't actually have
> to allocate an intermediate internal property descriptor, but
> immediately create an Object copy.
Tell me if I'm wrong, but if implementations can get rid of the extra
allocation, so could the spec, no? (that's what Allen suggests in his
answer).

>  
>
>     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 backwards-compatible.
... but it may be a corner-case that can be changed if not depended upon
by content on the web. It has happen many times already. Whether it can
be done in this particular case would require research.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121102/35974133/attachment.html>


More information about the es-discuss mailing list