Property Descriptors as script compatible representation
Tom Van Cutsem
tomvc.be at gmail.com
Fri Nov 2 06:07:45 PDT 2012
2012/11/2 David Bruant <bruant.d at gmail.com>
> Le 02/11/2012 12:20, Tom Van Cutsem a écrit :
> It is to avoid the lossy conversion that otherwise occurs between the
> return value of [[GetOwnProperty]] and Object.getOwnPropertyDescriptor.
> Just to be sure I fully understand: what is the loss exactly?
> I see that custom property descriptor attributes would be stripped out
> (because FromPropertyDescriptor outputs an object with 4 props mapping
> 1-to-1 to an accessor or data property descriptor).
> Is there another loss?
No, just the loss of custom attributes.
> If that's the only thing, redefining the property descriptor type to
> accept any field would prevent that loss. Such a change would be more
> aligned with the intention in the proxy spec of letting internal operations
> manipulate custom attributes passed to Object.defineProperty.
> I'm arguing in favor of switching to a script-usable type, but the change
> I mention can occur in the spec-only type.
I went ahead and refactored the Proxy spec to inline Aux.3
NormalizePropertyDescriptor and Aux.4
NormalizeAndCompletePropertyDescriptor . The new behavior is identical
- both TrapGetOwnProperty and TrapDefineOwnProperty do one less needless
conversion from Object to PropDesc
- both TrapGetOwnProperty and TrapDefineOwnProperty can now do all
invariant checks against an internal PropDesc instead of against a
normalized property descriptor Object
- in TrapGetOwnProperty, we can defer conversion from PropDesc to Object,
and copying of custom attributes, to the last possible moment, only after
all the invariant checks succeed.
To my mind, this refactoring further reduces the need for some new
script-usable property descriptor type.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss