Minor type confusion in proxies proposal?

Tom Van Cutsem tomvc.be at gmail.com
Tue Jul 12 12:29:17 PDT 2011


Follow-up:

- I updated <
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics> to reflect
our current consensus: the input descriptor to defineProperty and the return
value of get{Own}PropertyDescriptor is automatically "normalized" (see
[[Get{Own}Property]], [[DefineOwnProperty]],
Object.get{Own}PropertyDescriptor, Object.defineProperty). I also added an
auxiliary "NormalizePropertyDescriptor" operation that formalizes the notion
of "normalizing" a property descriptor.

- I added a rationale for how to treat property descriptors under the "Open
issues" section of the proxy proposal: <
http://wiki.ecmascript.org/doku.php?id=harmony:proxies#property_descriptor_normalization>
That section also informally describes what it means for a descriptor to be
"normalized".

Cheers,
Tom

2011/7/8 Tom Van Cutsem <tomvc.be at gmail.com>

> 2011/7/8 Andreas Rossberg <rossberg at google.com>
>
>> Likewise, invoking Object.getOwnPropertyDescriptor on a proxy does not
>> return user attributes. That actually is explicitly noted in the
>> semantics for [[GetOwnProperty]], but I'm not sure I see the rationale
>> behind it.
>>
>> I would prefer a more coherent story with respect to proxies and user
>> attributes on descriptor objects. That is, we should either support
>> such attributes properly, i.e. have them consistently flow both ways
>> (from clients to traps and vice versa). Or we do not support them at
>> all, i.e. filter them out everywhere.
>>
>
> I believe the note at [[GetOwnProperty]] predates our thoughts on allowing
> user-defined attributes. So yes, we should be consistent and perform the
> same type of "normalization" of property descriptors as for defineProperty.
>
>
>> /Andreas
>>
>>
>> On 8 July 2011 10:59, Andreas Rossberg <rossberg at google.com> wrote:
>> > It seems like we need to make a change to Object.defineProperties, too
>> > (regardless of the other issue). With the current wording, it will not
>> > forward user attributes to the defineProperty trap. The most modular
>> > fix (that seems compatible with your proposal below) probably is to
>> > change the spec of defineProperties to go through defineProperty,
>> > instead of calling the internal [[DefineOwnProperty]] directly.
>> >
>> > /Andreas
>> >
>> >
>> > On 6 July 2011 14:55, Andreas Rossberg <rossberg at google.com> wrote:
>> >> On 3 July 2011 13:29, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> >>> Comments?
>> >>
>> >> Looks good to me. I agree with Mark's comment that it should do a
>> >> (shallow) copy of the attributes object, though. I guess the obvious
>> >> point would be in Object.defineProperty, before passing it to
>> >> DefineProxyProperty.
>> >>
>> >> /Andreas
>> >>
>> >>
>> >>> 2011/7/2 Andreas Rossberg <rossberg at google.com>
>> >>>>
>> >>>> Hi Tom.
>> >>>>
>> >>>> On 2 July 2011 13:50, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> >>>> > Hi Andreas,
>> >>>> > First, you're right about the typing issue:
>> >>>> > In ES5, for values of type Object, the signature for
>> >>>> > [[DefineOwnProperty]]
>> >>>> > would be:
>> >>>> > [[DefineOwnProperty]](P: a property name, Desc: an internal
>> property
>> >>>> > descriptor, Throw: a boolean)
>> >>>> > On trapping proxies, that signature would need to change to:
>> >>>> > [[DefineOwnProperty]](P: a property name, Desc: an Object, Throw: a
>> >>>> > boolean)
>> >>>>
>> >>>> I don't think such a change is consistent. [[DefineOwnProperty]] is
>> >>>> invoked in a number of places in the spec, and I think in many of
>> them
>> >>>> the type of the receiver is not distinguished and may well be a
>> proxy,
>> >>>> so a proxy may then receive both kinds of descriptors. Moreover, I
>> >>>> think it would be a mistake to make the appropriate case distinction
>> >>>> everywhere -- you really want the internal method to have the same
>> >>>> signature in all cases.
>> >>>>
>> >>>> > With that, I believe the strawman is otherwise internally
>> consistent. In
>> >>>> > [[DefineOwnProperty]] step 5, what will be passed to the
>> user-defined
>> >>>> > "defineProperty" trap is a proper Object, not an internal
>> descriptor.
>> >>>> > I did clarify the note you referred to, to be more explicit in this
>> >>>> > regard.
>> >>>> > I don't see an alternative to changing the signature of
>> >>>> > [[DefineOwnProperty]]. It can't just receive an internal
>> descriptor, as
>> >>>> > it
>> >>>> > doesn't preserve any non-standard attributes.
>> >>>>
>> >>>> How about simply bypassing [[DefineOwnProperty]] in
>> >>>> Object.defineProperty for proxies, as I suggested in my reply to
>> >>>> David? That seems to be the only place where additional objects can
>> >>>> occur, or am I wrong?
>> >>>>
>> >>>> Cheers,
>> >>>> /Andreas
>> >>>>
>> >>>>
>> >>>> > 2011/7/1 Andreas Rossberg <rossberg at google.com>
>> >>>> >>
>> >>>> >> 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
>> >>>> >> >
>> >>>> >> _______________________________________________
>> >>>> >> es-discuss mailing list
>> >>>> >> es-discuss at mozilla.org
>> >>>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110712/492febfc/attachment.html>


More information about the es-discuss mailing list