Re: Non-constructible constructors and Arrays

On 8/3/11, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

I get where you're coming from, here, Cameron.

Should the implicit sometimes-an-error-is-thrown instead be an
explicit "an error is thrown" for frozen or sealed cases?

As it is now, error conditions depend on the object's state (sealed,
fixed, or free), the method called, and the arguments and their
values. Array.prototype.slice on a sealed object can provide other
examples of sometimes-an-error-is-thrown.

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

Maybe it's just me, but the sometimes-an-error-is-thrown seems kind of odd.
-- 
Garrett

Received on Saturday, 6 August 2011 16:51:10 UTC