Minor type confusion in proxies proposal?

Andreas Rossberg rossberg at google.com
Sat Jul 2 10:17:45 PDT 2011


Yes, I understand the intent, I'm just pointing out that the current
spec is both

- incomplete, because it seems to assume that the semantics of the
internal object descriptor type is extended, without specifying that,
and

- inconsistent, because attributes objects are passed to functions
expecting descriptors (Object.defineProperty invoking
[[DefineOwnProperty]] for proxies), and vice versa,
([[DefineOwnProperty]] invoking the proxy trap), without proper
conversions.

Of course, that can be fixed. The easiest fix (and what Tom perhaps
had in mind) probably is to leave alone the definition of property
descriptors, and have Object.defineProperty call the proxy trap
directly, without going through [[DefineOwnProperty]]. That avoids the
redundant conversion back and forth and trivially allows to keep
additional properties on the attributes object. Or do you envision
additional ways where extended attributes could come in?

/Andreas

On 1 July 2011 21:21, David Bruant <david.bruant at labri.fr> wrote:
> Hi Andreas,
>
> Property descriptors as specific "type" is an internal construct of the
> ES spec. Their definition in ES5 was used in the context of ES5 (with
> normal objects, host objects but no proxies). The proxy API needed a way
> to represent them. Objects sound like the natural construct to do so.
>
> First, you have to notice that the object is copied, so a different
> object is passed as argument to the defineProperty trap and as argument
> within the trap. Same for the return value of getOwnPropertyDescriptor.
> So there is no way the proxy can magically change a property descriptor
> (since within the proxy, there are only proxies)
> Then, the intention behind letting custom attribute pass is to encourage
> innovation.
> Proxies have the potential to be arbitrarily complicated; so should be
> their "dialog" interface (defineProperty, getOwnPropertyDescriptor). For
> instance, in an experiment of mine [1], I use a custom "index" property
> attribute. If some good idea come out (unlike my experiment), they could
> be integrated to a next version of ECMAScript.
>
> So I agree that objects as property descriptors within traps instead of
> a custom type are a derivation from the spec, but I think it's a good thing.
>
> Tom: about "...except that it also retains any non-standard attributes
> present in the original property descriptor passed to
> Object.defineProperty.", what do you mean by "any"?
> Is it Object.keys(desc)?
> Object.enumerate(desc) (I mean the prop list enumerated over with for-in)?
> Object.getOwnPropertyNames(desc)?
>
> David
>
> [1] https://github.com/DavidBruant/PropStackObjects (see the HTMLs to
> see how it works)
>
> Le 01/07/2011 14:54, Andreas Rossberg a écrit :
>> On 1 July 2011 12:12, Andreas Rossberg <rossberg at google.com> wrote:
>>> I believe there is some "type" confusion in the proxy proposal spec
>>> wrt property descriptors and their reification into attributes
>>> objects.
>>>
>>> 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal says:
>>>
>>> "The Desc argument to this trap is a property descriptor object
>>> validated by ToPropertyDescriptor, except that it also retains any
>>> non-standard attributes present in the original property descriptor
>>> passed to Object.defineProperty. See the semantics of the modified
>>> Object.defineProperty built-in, below."
>>>
>>> That seems fishy, since according to ES5 8.10:
>>>
>>> "Values of the Property Descriptor type are records composed of named
>>> fields where each field‘s name is an attribute name and its value is a
>>> corresponding attribute value as specified in 8.6.1."
>>>
>>> In particular, I take this to mean that property descriptors are not
>>> objects (but abstract records), and that there cannot be any fields
>>> whose name is not an attribute name. (In fact, in V8 we currently
>>> encode property descriptors using objects, but the encoding is
>>> different from the reified attributes object representation, and not
>>> quite compatible with the idea of adding arbitrary other fields.)
>> I forgot to say: step 5 of the definition invokes the defineProperty
>> trap of the handler passing Desc as the second argument. But the
>> handler expects a reified attributes object.
>>
>>> 2. In the modified definition of Object.defineProperty, the proposal
>>> says in step 4.c:
>>>
>>> "Call the [[DefineOwnProperty]] internal method of O with arguments
>>> name, descObj, and true."
>>>
>>> This is passing descObj, which in fact is _not_ a descriptor, but its
>>> reification as an attributes object.
>>>
>>> /Andreas
>
>


More information about the es-discuss mailing list