Proxies: wrong "receiver" used in default "set" trap

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Dec 20 12:30:28 PST 2012


On Dec 20, 2012, at 12:12 PM, Tom Van Cutsem wrote:

> 2012/12/20 Allen Wirfs-Brock <allen at wirfs-brock.com>
> Yes, here is the new step 5 as I have just updated it in my spec. draft (ignore the 1, it's really 5) 
> If IsDataDescriptor(ownDesc) is true, then
> If ownDesc.[[Writable]] is false, return false.
> If Type(Receiver) is not Object, return false.
> Let existingDescriptor be be the result of calling the [[GetOwnProperty]] internal method of Receiver with argument P.
> ReturnIfAbrupt(existingDescriptor).
> If existingDescriptor is not undefined, then
> Let valueDesc be the Property Descriptor {[[Value]]: V}.
> Return the result of calling the [[DefineOwnProperty]] internal method of Receiver with arguments P and valueDesc.
> Else Receiver does not currently have a property P,
> Return the result of performing CreateOwnDataProperty(Receiver, P, V).
> 
> Allen
> 
> Looks good!
> 
> As you note, with the introduction of a user-facing Reflect.set function, Receiver can be an arbitrary object. Thus, it may be that existingDescriptor denotes an accessor property, in which case the [[DefineOwnProperty]] call will fail, but this is perfectly acceptable.

Maybe not fail.  If existingDescriptor is an accessor descriptor with  [[Configurable]]: true, then the [[DefineOwnProperty]] call will convert the property into a data property.  But maybe that is also ok as this situation could only occur  via direct use of Reflect.put or perhaps a strangely defined proxy handler.  Both of those are new situations where we are free to define the semantics.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/06c31d6e/attachment.html>


More information about the es-discuss mailing list