May the defineProperty method of a proxy handler throw a TypeError?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Mark S. Miller-2


On Sun, Jun 19, 2011 at 8:22 AM, Tom Van Cutsem <tomvc.be@gmail.com> wrote:
2011/6/18 David Bruant <[hidden email]>
Le 18/06/2011 00:47, David Flanagan a écrit :
> Given that the fixed properties proposal is adding a return value to
> defineProperty, perhaps returning false would be a suitable way to
> reject a property definition.

Yes, I think such an API could work.
 
I would see this as a weird semantic collision. If I return undefined,
should it be considered as a falsy value or an inappropriate property
descriptor? If I return {} or [], is it a truthy value or an invalid
property descriptor?

- |undefined| is falsy, so interpret as a reject.
- {} is a valid, empty property descriptor.
- For [], or any other non-falsy, non-object value either one could 1) ignore such values, 2) interpret them as 'rejects', or 3) interpret them as illegal property descriptors, which should trigger a TypeError. I would opt for 3), as if the internal Proxy code does:

let res = handler.defineProperty(...);
if (res) {
  desc = ToPropertyDescriptor(res); // throws TypeError if res is a non-Object value
  ...
} else {
  reject();
}

But before continuing this discussion, I'd like to take measure of how important it actually is for the Proxy API to be able to faithfully emulate ES5.1 reject behavior in non-strict mode. Say some non-strict ES5.1 code is executing Object.defineProperty(...) on a proxy and it throws a TypeError rather than failing silently. Is that a big deal or just a minor annoyance?

There might be a misunderstanding here. If ES5.1 strict or non-strict code explicitly calls Object.defineProperty(...) then (15.2.3.6 step 4) the [[DefineOwnProperty]] method is called with a Throw  argument of true. So a failed explicit call to Object.defineProperty(...) always throws, regardless of the strictness of its caller. 

To do otherwise would be to make the dynamic scoping mistake, since Object.defineProperty is first class, not a special form.


 
As Mark recently mentioned, to ES5.1 code, proxies are like host objects, which may already trigger such behavior anyway. OTOH, it might preclude the use of Proxies to transparently wrap existing ES5.1 objects.

Cheers,
Tom



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem-3
2011/6/19 Mark S. Miller <[hidden email]>
On Sun, Jun 19, 2011 at 8:22 AM, Tom Van Cutsem <tomvc.be@gmail.com> wrote:
But before continuing this discussion, I'd like to take measure of how important it actually is for the Proxy API to be able to faithfully emulate ES5.1 reject behavior in non-strict mode. Say some non-strict ES5.1 code is executing Object.defineProperty(...) on a proxy and it throws a TypeError rather than failing silently. Is that a big deal or just a minor annoyance?

There might be a misunderstanding here. If ES5.1 strict or non-strict code explicitly calls Object.defineProperty(...) then (15.2.3.6 step 4) the [[DefineOwnProperty]] method is called with a Throw  argument of true. So a failed explicit call to Object.defineProperty(...) always throws, regardless of the strictness of its caller. 

To do otherwise would be to make the dynamic scoping mistake, since Object.defineProperty is first class, not a special form.

You're right, the problem is not with Object.defineProperty but rather with [[Put]] / the set trap (since it defaults to [[DefineOwnProperty]] / the defineProperty trap, and it is dependent on the strictness of the caller). But my question remains: how important is it for a Proxy to be able to faithfully emulate the reject behavior of assignment in non-strict code? If it is important then we should probably have the defineProperty trap return a success value, just like delete or set.

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

David Flanagan-2
On 6/20/11 1:13 AM, Tom Van Cutsem wrote
[https://mail.mozilla.org/pipermail/es-discuss/2011-June/015352.html]:
> But my question remains: how important is it for a Proxy to be able to
> faithfully emulate the reject behavior of assignment in non-strict
> code? If it is important then we should probably have the
> defineProperty trap return a success value, just like delete or set.

No one seems to have answered the question. Maybe that means it is not
so important. The one data point I'd like to add is that WebIDL (§4.7.3
and elsewhere) is written to use the ECMA-262 Reject operation. If Proxy
can't correctly emulate reject behavior in non-strict code, then I can't
correctly implement the DOM in JavaScript.

On 6/17/11, Cameron McCormack wrote
[http://lists.w3.org/Archives/Public/public-script-coord/2011AprJun/0209.html]:
> It seems like proxies should allow throwing/ignoring based on strict
> modeness of the caller.  I’ll leave the requirements to Reject in there
> for now.
Since WebIDL is in last-call status, this is probably a good time to
decide whether the proxy proposal should change to allow faithful
emulation of Reject, or whether WebIDL should change to throw a
TypeError instead of using Reject...

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Mark S. Miller-2
On Mon, Aug 8, 2011 at 2:20 PM, David Flanagan <[hidden email]> wrote:
[...]
Since WebIDL is in last-call status, this is probably a good time to decide whether the proxy proposal should change to allow faithful emulation of Reject, or whether WebIDL should change to throw a TypeError instead of using Reject...

If there are no show-stopping legacy compat constraints forcing us to specify Reject, I prefer that we specify these to throw a TypeError.
 

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Cameron McCormack-4
On 9/08/11 9:40 AM, Mark S. Miller wrote:
> If there are no show-stopping legacy compat constraints forcing us to
> specify Reject, I prefer that we specify these to throw a TypeError.

I can't say for sure, but I would be surprised if this didn't cause
problems, given that it introduces exception throwing where currently
assignment to non-writable properties of objects that need to be
implemented as proxies (like NodeList) is just ignored.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Mark S. Miller-2
On Wed, Aug 10, 2011 at 7:20 PM, Cameron McCormack <[hidden email]> wrote:
On 9/08/11 9:40 AM, Mark S. Miller wrote:
If there are no show-stopping legacy compat constraints forcing us to
specify Reject, I prefer that we specify these to throw a TypeError.

I can't say for sure, but I would be surprised if this didn't cause problems, given that it introduces exception throwing where currently assignment to non-writable properties of objects that need to be implemented as proxies (like NodeList) is just ignored.

Ok. If we decide not to, then I think it is important that proxies be able to faithfully emulate ES5 failed "Reject" semantics, so that ES-next code can fully implement a conformant DOM.

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem-3
2011/8/11 Mark S. Miller <[hidden email]>
On Wed, Aug 10, 2011 at 7:20 PM, Cameron McCormack <[hidden email]> wrote:
On 9/08/11 9:40 AM, Mark S. Miller wrote:
If there are no show-stopping legacy compat constraints forcing us to
specify Reject, I prefer that we specify these to throw a TypeError.

I can't say for sure, but I would be surprised if this didn't cause problems, given that it introduces exception throwing where currently assignment to non-writable properties of objects that need to be implemented as proxies (like NodeList) is just ignored.

Ok. If we decide not to, then I think it is important that proxies be able to faithfully emulate ES5 failed "Reject" semantics, so that ES-next code can fully implement a conformant DOM.

Noted. I'll write up a small strawman to change the signature of 'defineProperty' to return a boolean success value. This change should be fully compatible with the existing API, as the return value of the 'defineProperty' trap is currently ignored.

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem-3
2011/8/11 Tom Van Cutsem <[hidden email]>
Noted. I'll write up a small strawman to change the signature of 'defineProperty' to return a boolean success value. This change should be fully compatible with the existing API, as the return value of the 'defineProperty' trap is currently ignored.


One upwards-compatibility hazard I see is that all current Proxy code that does not explicitly return a value from its |defineProperty| trap, implicitly returns |undefined|, which is coerced to |false|. That is probably not the behavior that was intended.

So, to future-proof if this strawman is accepted, I think it's best to let existing |defineProperty| traps |return true;|.

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Cameron McCormack-4
On 15/08/11 8:58 PM, Tom Van Cutsem wrote:
> So, to future-proof if this strawman is accepted, I think it's best to
> let existing |defineProperty| traps |return true;|.

By that do you mean interpret an undefined return value as meaning
"don't throw"?  Sounds reasonable.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem-3
2011/8/15 Cameron McCormack <[hidden email]>
On 15/08/11 8:58 PM, Tom Van Cutsem wrote:
So, to future-proof if this strawman is accepted, I think it's best to
let existing |defineProperty| traps |return true;|.

By that do you mean interpret an undefined return value as meaning "don't throw"?  Sounds reasonable.

No, that's not what I meant. We could consider it, but then the same meaning should apply to the 'set' and 'delete' traps.

What I meant was that existing Proxy code (in which defineProperty doesn't need to return a boolean success value) is not upwards-compatible with this strawman. If a defineProperty trap does not return a value (or returns undefined), under this strawman that indicates a failed defineProperty invocation, which is most probably not what the original code intended. If proxy authors want to anticipate acceptance of this strawman, they can do so by having defineProperty traps |return true;| already. We need to discuss this change at the next TC39 meeting, but I don't currently see any reason why it would not be accepted into the proxies proposal.

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12