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 <[email protected]> > 2011/7/8 Andreas Rossberg <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> wrote: >> >> On 3 July 2011 13:29, Tom Van Cutsem <[email protected]> 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 <[email protected]> >> >>>> >> >>>> Hi Tom. >> >>>> >> >>>> On 2 July 2011 13:50, Tom Van Cutsem <[email protected]> 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 <[email protected]> >> >>>> >> >> >>>> >> On 1 July 2011 12:12, Andreas Rossberg <[email protected]> >> 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 >> >>>> >> [email protected] >> >>>> >> https://mail.mozilla.org/listinfo/es-discuss >> >>>> > >> >>>> > >> >>> >> >>> >> >> >> > >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
