Re: Minor type confusion in proxies proposal?
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...@gmail.com
2011/7/8 Andreas Rossberg rossb...@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 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
Re: Minor type confusion in proxies proposal?
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
Re: Minor type confusion in proxies proposal?
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
Re: Minor type confusion in proxies proposal?
2011/7/8 Andreas Rossberg rossb...@google.com 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. I agree. Noted. /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
Re: Minor type confusion in proxies proposal?
2011/7/8 Andreas Rossberg rossb...@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 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
Re: Minor type confusion in proxies proposal?
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
Re: Minor type confusion in proxies proposal?
On Sun, Jul 3, 2011 at 12:00 PM, Mark S. Miller erig...@google.com wrote: Here is a possible revised semantics for [[DefineOwnProperty]] on trapping proxies, and the Object.defineProperty built-in: [[DefineOwnProperty]] (P, Desc, Throw) When the [[DefineOwnProperty]] internal method of a trapping proxy O is called with property name P, property descriptor Desc and Boolean flag Throw, the following steps are taken: 1. Let descObj be FromGenericPropertyDescriptor(Desc) // see harmony:proxies_semantics page 2. Return DefineProxyProperty(O, P, descObj, Throw) DefineProxyProperty (Proxy, P, DescObj, Throw) When the DefineProxyProperty auxiliary function is called with a trapping proxy Proxy, a property name P, an Object DescObj and a Boolean flag Throw, the following steps are taken: 1. Let handler be the value of the [[Handler]] internal property of Proxy. 2. Let defineProperty be the result of calling the [[Get]] internal method of handler with argument “defineProperty”. 3. If defineProperty is undefined, throw a TypeError exception. 4. If IsCallable(defineProperty) is false, throw a TypeError exception. 5. Let trapResult be the result of calling the [[Call]] internal method of defineProperty providing handler as the this value, P as the first argument and DescObj as the second argument. This pass-through without protective copying is too hazardous. It means each handler must individually protect itself, not only against accessor behavior, but against the caller changing the shared DescObj after the fact. I think if an Object.toPropertyDescriptor function were introduced, then this protection burden may be sufficiently small. This would be similar to the FixedHandler approach of providing *optional* builtin invariant maintenance support. The first argument to this function would be the object to convert to a property descriptor, and there could potentially be a second argument which could be a boolean as to whether to keep non-standard attributes. 6. Let success be ToBoolean(trapResult) 7. If success is false, reject 8. Return true Object.defineProperty (O, P, Attributes) 1. If Type(O) is not Object throw a TypeError exception. 2. Let name be ToString(P). 3. If O is a trapping proxy a. Call DefineProxyProperty(O, name, Attributes, true) b. Return O. 4. Let desc be the result of ToPropertyDescriptor(Attributes) 5. Call the [[DefineOwnProperty]] internal method of O with arguments name, desc, and true. 6. Return O. Cheers, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
Hi Andreas, Bypassing [[DefineOwnProperty]] in Object.defineProperty for proxies could work. It would also totally bypass the question of how non-standard attributes are identified or need to be copied, as the property descriptor argument to Object.defineProperty can be passed directly to the trap. Mark: would this introduce any security concerns? One potential issue I see is that standard attributes may be defined as accessor rather than data properties, which means they can report different values over time. Here is a possible revised semantics for [[DefineOwnProperty]] on trapping proxies, and the Object.defineProperty built-in: [[DefineOwnProperty]] (P, Desc, Throw) When the [[DefineOwnProperty]] internal method of a trapping proxy O is called with property name P, property descriptor Desc and Boolean flag Throw, the following steps are taken: 1. Let descObj be FromGenericPropertyDescriptor(Desc) // see harmony:proxies_semantics page 2. Return DefineProxyProperty(O, P, descObj, Throw) DefineProxyProperty (Proxy, P, DescObj, Throw) When the DefineProxyProperty auxiliary function is called with a trapping proxy Proxy, a property name P, an Object DescObj and a Boolean flag Throw, the following steps are taken: 1. Let handler be the value of the [[Handler]] internal property of Proxy. 2. Let defineProperty be the result of calling the [[Get]] internal method of handler with argument “defineProperty”. 3. If defineProperty is undefined, throw a TypeError exception. 4. If IsCallable(defineProperty) is false, throw a TypeError exception. 5. Let trapResult be the result of calling the [[Call]] internal method of defineProperty providing handler as the this value, P as the first argument and DescObj as the second argument. 6. Let success be ToBoolean(trapResult) 7. If success is false, reject 8. Return true Object.defineProperty (O, P, Attributes) 1. If Type(O) is not Object throw a TypeError exception. 2. Let name be ToString(P). 3. If O is a trapping proxy a. Call DefineProxyProperty(O, name, Attributes, true) b. Return O. 4. Let desc be the result of ToPropertyDescriptor(Attributes) 5. Call the [[DefineOwnProperty]] internal method of O with arguments name, desc, and true. 6. Return O. Comments? 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
Re: Minor type confusion in proxies proposal?
On Sun, Jul 3, 2011 at 4:29 AM, Tom Van Cutsem tomvc...@gmail.com wrote: Hi Andreas, Bypassing [[DefineOwnProperty]] in Object.defineProperty for proxies could work. It would also totally bypass the question of how non-standard attributes are identified or need to be copied, as the property descriptor argument to Object.defineProperty can be passed directly to the trap. Mark: would this introduce any security concerns? One potential issue I see is that standard attributes may be defined as accessor rather than data properties, which means they can report different values over time. Yes. I'm not against a pass through, but only if, for the standard attributes (or possibly all) we do all the value-to-value protective copying of the current system. The descriptor object given to the trap should have only data properties, at least for the properties representing standard attributes. Here is a possible revised semantics for [[DefineOwnProperty]] on trapping proxies, and the Object.defineProperty built-in: [[DefineOwnProperty]] (P, Desc, Throw) When the [[DefineOwnProperty]] internal method of a trapping proxy O is called with property name P, property descriptor Desc and Boolean flag Throw, the following steps are taken: 1. Let descObj be FromGenericPropertyDescriptor(Desc) // see harmony:proxies_semantics page 2. Return DefineProxyProperty(O, P, descObj, Throw) DefineProxyProperty (Proxy, P, DescObj, Throw) When the DefineProxyProperty auxiliary function is called with a trapping proxy Proxy, a property name P, an Object DescObj and a Boolean flag Throw, the following steps are taken: 1. Let handler be the value of the [[Handler]] internal property of Proxy. 2. Let defineProperty be the result of calling the [[Get]] internal method of handler with argument “defineProperty”. 3. If defineProperty is undefined, throw a TypeError exception. 4. If IsCallable(defineProperty) is false, throw a TypeError exception. 5. Let trapResult be the result of calling the [[Call]] internal method of defineProperty providing handler as the this value, P as the first argument and DescObj as the second argument. This pass-through without protective copying is too hazardous. It means each handler must individually protect itself, not only against accessor behavior, but against the caller changing the shared DescObj after the fact. 6. Let success be ToBoolean(trapResult) 7. If success is false, reject 8. Return true Object.defineProperty (O, P, Attributes) 1. If Type(O) is not Object throw a TypeError exception. 2. Let name be ToString(P). 3. If O is a trapping proxy a. Call DefineProxyProperty(O, name, Attributes, true) b. Return O. 4. Let desc be the result of ToPropertyDescriptor(Attributes) 5. Call the [[DefineOwnProperty]] internal method of O with arguments name, desc, and true. 6. Return O. Comments? 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
Re: Minor type confusion in proxies proposal?
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) 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. Cheers, Tom 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
Re: Minor type confusion in proxies proposal?
2011/7/1 David Bruant david.bru...@labri.fr 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)? I meant any own properties of the argument, regardless of enumerability (i.e. as determined by Object.getOwnPropertyNames). This is consistent with the modifications to Object.defineProperty, step 4.b. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
2011/7/2 Mark S. Miller erig...@google.com On Fri, Jul 1, 2011 at 2:55 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote: In our implementation we are using a generic object. It has some overhead, and a specific internal descriptor object representation might be a bit faster, but such magic objects that don't allow expando properties are usually pretty surprising to programers. Most of the HTML5 DOM allows arbitrary expando properties. I think we should stick to that theme. IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to extend property descriptors with .required and other ad-hoc (expando) properties. This is important: it allows developers to blaze trails and tread paths that we later pave with standards. These are present in the user visible descriptor objects, but traits.js does not assume they are preserved in the internal descriptors. It can't assume that, since trait.js works on current ES5 browsers whose internal descriptors don't. Maybe Tom has thought about it, but we haven't discussed how this change would effect traits.js. My guess it is would have a positive effect. Tom? Indeed, traits.js can get by without requiring non-standard attributes to be interned. However, part of the reason why we could get away with this is because we could roughly encode the semantics of properties marked required: true and conflict: true in terms of standard attributes. For example, a property marked as required: true indicates an abstract property that should be invisible on a trait instance. We encoded such a property as an enumerable: false, value: undefined data property, to make it as invisible as possible in practice (yet the in-operator or the introspective Object.* methods would still reveal it). With proxies that relay non-standard attributes, one would have the option to encode trait instances as proxies that can retain and enforce all trait semantics. For traits.js in particular, we wouldn't actually encode trait instances as proxies as our encoding happens to be sufficient for practical needs. But as David's experiment shows, who knows what attributes developers will come up with, and what semantics they will want to associate with those attributes. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
Le 02/07/2011 13:53, Tom Van Cutsem a écrit :
2011/7/1 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
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)?
I meant any own properties of the argument, regardless of
enumerability (i.e. as determined by Object.getOwnPropertyNames). This
is consistent with the modifications to Object.defineProperty, step 4.b.
Actually, in ES5 the ToPropertyDescriptor function (8.10.5) (used in the
original Object.defineProperty step 3 (and your version too)) calls
[[HasProperty]] and [[Get]] on the object expected to become a property
descriptor, meaning that the prototype is climbed.
-
// Currently, for ToPropertyDescriptor (and Object.defineProperty as a
consequence),
null | {enumerable:true, configurable:false} | {set: function(){},
get:function(){}}
// is equivalent to
{set: function(){}, get:function(){}, enumerable:true, configurable:false}
// because it calls [[HasProperty]] and [[Get]]
// Sorry for the harmony:proto_operator notation abuse. I'm not sure I
can chain it.
-
I'm afraid that if we do not climb the prototype at all now, there might
be inconsistencies if later the spec standardized custom attributes.
In the case of a custom attribute is put in the prototype now, it won't
be passed to a proxy, while it will whenever this attribute becomes part
of a later version of the standard (because I assume that for
consistency sake, [[HasProperty]] and [[Get]] will be used too to
retrieve it).
This may create complicated bugs to notice. (think about a trap looping
over property descriptor attributes. standardizing more attribute could
change the number of attributes looped over)
I would recommand to climb the prototype to detect custom attributes
since that's what the ToPropertyDescriptor algorithm does. Of course,
passing every single property is stupid since it would pass things like
'hasOwnProperty' (retrieved from Object.prototype), hence the idea of
filtering out non-enumerable properties.
Maybe the set of properties passed to the trap could be the union of
Object.getOwnPropertyNames and Object.enumerate (for-in loops)?
Maybe it's already time to add a custom property descriptor like
notAPropertyAttribute (defauting to false, sorry for double negation)?
Another alternative is changing ToPropertyDescriptor, but I think it's
too late now.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
You're right, including inherited attributes would be more consistent with
the current ES5 behavior.
Since the proxy needs to loop over the properties of the property
descriptor object, what better abstraction to mimic than the for-in loop?
I.e. it is probably easiest for programmers to figure out what's going on if
proxies detect custom attributes by doing:
for (var attr in propertyDescriptorObject) {
... // copy all non-standard attributes into a fresh property descriptor
object
}
That is: custom attributes are all own or inherited, enumerable property
names of the property descriptor object, and overridden attribute values get
priority over inherited attribute values.
Does that sound right?
2011/7/2 David Bruant david.bru...@labri.fr
Le 02/07/2011 13:53, Tom Van Cutsem a écrit :
2011/7/1 David Bruant david.bru...@labri.fr
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)?
I meant any own properties of the argument, regardless of enumerability
(i.e. as determined by Object.getOwnPropertyNames). This is consistent with
the modifications to Object.defineProperty, step 4.b.
Actually, in ES5 the ToPropertyDescriptor function (8.10.5) (used in the
original Object.defineProperty step 3 (and your version too)) calls
[[HasProperty]] and [[Get]] on the object expected to become a property
descriptor, meaning that the prototype is climbed.
-
// Currently, for ToPropertyDescriptor (and Object.defineProperty as a
consequence),
null | {enumerable:true, configurable:false} | {set: function(){},
get:function(){}}
// is equivalent to
{set: function(){}, get:function(){}, enumerable:true, configurable:false}
// because it calls [[HasProperty]] and [[Get]]
// Sorry for the harmony:proto_operator notation abuse. I'm not sure I can
chain it.
-
I'm afraid that if we do not climb the prototype at all now, there might be
inconsistencies if later the spec standardized custom attributes.
In the case of a custom attribute is put in the prototype now, it won't be
passed to a proxy, while it will whenever this attribute becomes part of a
later version of the standard (because I assume that for consistency sake,
[[HasProperty]] and [[Get]] will be used too to retrieve it).
This may create complicated bugs to notice. (think about a trap looping
over property descriptor attributes. standardizing more attribute could
change the number of attributes looped over)
I would recommand to climb the prototype to detect custom attributes since
that's what the ToPropertyDescriptor algorithm does. Of course, passing
every single property is stupid since it would pass things like
'hasOwnProperty' (retrieved from Object.prototype), hence the idea of
filtering out non-enumerable properties.
Maybe the set of properties passed to the trap could be the union of
Object.getOwnPropertyNames and Object.enumerate (for-in loops)?
Maybe it's already time to add a custom property descriptor like
notAPropertyAttribute (defauting to false, sorry for double negation)?
Another alternative is changing ToPropertyDescriptor, but I think it's too
late now.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
Le 02/07/2011 15:21, Tom Van Cutsem a écrit :
You're right, including inherited attributes would be more consistent
with the current ES5 behavior.
Since the proxy needs to loop over the properties of the property
descriptor object, what better abstraction to mimic than the for-in
loop? I.e. it is probably easiest for programmers to figure out what's
going on if proxies detect custom attributes by doing:
for (var attr in propertyDescriptorObject) {
... // copy all non-standard attributes into a fresh property
descriptor object
}
That is: custom attributes are all own or inherited, enumerable
property names of the property descriptor object, and overridden
attribute values get priority over inherited attribute values.
Does that sound right?
So the set of attributes would be the union of standard attributes
(regardless of enumerability) and properties retrieved through for-in if
I understand well.
It sounds like if the standard attribute set changes over time, code
could break, but it also looks like an intricable problem, so I think
that this is the best trade-off.
David
2011/7/2 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Le 02/07/2011 13:53, Tom Van Cutsem a écrit :
2011/7/1 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
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)?
I meant any own properties of the argument, regardless of
enumerability (i.e. as determined by Object.getOwnPropertyNames).
This is consistent with the modifications to
Object.defineProperty, step 4.b.
Actually, in ES5 the ToPropertyDescriptor function (8.10.5) (used
in the original Object.defineProperty step 3 (and your version
too)) calls [[HasProperty]] and [[Get]] on the object expected to
become a property descriptor, meaning that the prototype is climbed.
-
// Currently, for ToPropertyDescriptor (and Object.defineProperty
as a consequence),
null | {enumerable:true, configurable:false} | {set:
function(){}, get:function(){}}
// is equivalent to
{set: function(){}, get:function(){}, enumerable:true,
configurable:false}
// because it calls [[HasProperty]] and [[Get]]
// Sorry for the harmony:proto_operator notation abuse. I'm not
sure I can chain it.
-
I'm afraid that if we do not climb the prototype at all now, there
might be inconsistencies if later the spec standardized custom
attributes.
In the case of a custom attribute is put in the prototype now, it
won't be passed to a proxy, while it will whenever this attribute
becomes part of a later version of the standard (because I assume
that for consistency sake, [[HasProperty]] and [[Get]] will be
used too to retrieve it).
This may create complicated bugs to notice. (think about a trap
looping over property descriptor attributes. standardizing more
attribute could change the number of attributes looped over)
I would recommand to climb the prototype to detect custom
attributes since that's what the ToPropertyDescriptor algorithm
does. Of course, passing every single property is stupid since it
would pass things like 'hasOwnProperty' (retrieved from
Object.prototype), hence the idea of filtering out non-enumerable
properties.
Maybe the set of properties passed to the trap could be the union
of Object.getOwnPropertyNames and Object.enumerate (for-in loops)?
Maybe it's already time to add a custom property descriptor like
notAPropertyAttribute (defauting to false, sorry for double
negation)?
Another alternative is changing ToPropertyDescriptor, but I think
it's too late now.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
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.bru...@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 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
Re: Minor type confusion in proxies proposal?
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
Minor type confusion in proxies proposal?
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.) 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
Re: Minor type confusion in proxies proposal?
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
Re: Minor type confusion in proxies proposal?
In our implementation we are using a generic object. It has some overhead, and a specific internal descriptor object representation might be a bit faster, but such magic objects that don't allow expando properties are usually pretty surprising to programers. Most of the HTML5 DOM allows arbitrary expando properties. I think we should stick to that theme. Andreas On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote: 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
Re: Minor type confusion in proxies proposal?
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 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
Re: Minor type confusion in proxies proposal?
On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote: In our implementation we are using a generic object. It has some overhead, and a specific internal descriptor object representation might be a bit faster, but such magic objects that don't allow expando properties are usually pretty surprising to programers. Most of the HTML5 DOM allows arbitrary expando properties. I think we should stick to that theme. IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to extend property descriptors with .required and other ad-hoc (expando) properties. This is important: it allows developers to blaze trails and tread paths that we later pave with standards. /be Andreas On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote: 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minor type confusion in proxies proposal?
On Fri, Jul 1, 2011 at 2:55 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote: In our implementation we are using a generic object. It has some overhead, and a specific internal descriptor object representation might be a bit faster, but such magic objects that don't allow expando properties are usually pretty surprising to programers. Most of the HTML5 DOM allows arbitrary expando properties. I think we should stick to that theme. IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to extend property descriptors with .required and other ad-hoc (expando) properties. This is important: it allows developers to blaze trails and tread paths that we later pave with standards. These are present in the user visible descriptor objects, but traits.js does not assume they are preserved in the internal descriptors. It can't assume that, since trait.js works on current ES5 browsers whose internal descriptors don't. Maybe Tom has thought about it, but we haven't discussed how this change would effect traits.js. My guess it is would have a positive effect. Tom? /be Andreas On Jul 1, 2011, at 5:54 AM, Andreas Rossberg wrote: 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
