W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

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

From: Tom Van Cutsem <tomvc.be@gmail.com>
Date: Tue, 16 Aug 2011 13:02:39 +0200
Message-ID: <CAKDfNj_+PFjhxyLYzLFpXsnhNaxeKN+8W4enj0hTAUjBm3Hj4w@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: "Mark S. Miller" <erights@google.com>, David Flanagan <dflanagan@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
2011/8/15 Cameron McCormack <cam@mcc.id.au>

> 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.

Received on Tuesday, 16 August 2011 11:03:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC