- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 04 Aug 2011 10:18:50 +1200
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, Jonas Sicking <jonas@sicking.cc>, Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On 4/08/11 6:36 AM, Garrett Smith wrote:
> You could use something like "frozen array" or "if the array is
> frozen, an error is thrown." Any API that does that builds on top of
> what ES5 does today, which lets frozen Arrays go through `reverse()`,
> waiting until step 6.h.i is called.
>
> You proposed that if one wants to find out if the method will throw or
> not, he must read the algorithm. I think that's too much to ask.
>
> The implication is that when then when the algorithm gets to a step
> that calls [[Put]] or [[Delete]], he must read through that, then read
> through [[Delete]]'s call to [[Configurable]], and all of that just to
> see if the method will throw. And then in reading through that, you
> see there are cases where the algorithm might not throw, even if
> [[Configurable]] and/or [[Writable]] is false. That's overwhelming.
I think for the purposes we're talking about here -- deciding which
methods to include on an array-like object defined in Web IDL -- it's
not whether the method will throw or not. Rather, I think we want to
know which methods intend to mutate the Array they are called on,
because probably all of them can throw if the properties they look up
are accessors that throw, such as
var a = [];
Object.defineProperty(a, "0", { get: function() { throw 1 } });
a.concat();
but I think we do want concat to be available on read only array-like
objects.
Similarly, the getter could be defined so that it tries to mutate the
array-like object, but that shouldn't disqualify it from being available.
Received on Wednesday, 3 August 2011 22:19:43 UTC