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. /Andreas On 8 July 2011 10:59, Andreas Rossberg <rossb...@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 <rossb...@google.com> wrote: >> On 3 July 2011 13:29, Tom Van Cutsem <tomvc...@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 <rossb...@google.com> >>>> >>>> Hi Tom. >>>> >>>> On 2 July 2011 13:50, Tom Van Cutsem <tomvc...@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 <rossb...@google.com> >>>> >> >>>> >> On 1 July 2011 12:12, Andreas Rossberg <rossb...@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@mozilla.org >>>> >> https://mail.mozilla.org/listinfo/es-discuss >>>> > >>>> > >>> >>> >> > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
