Re: Non-constructible constructors and Arrays

Isn't the key request for a way to be forward compatible with
ECMAScript? I think we want to be able to say "add all non mutating
methods from the ECMAScript Array.prototype to the Foo object", so an
implementation which supports a newer version of ECMAScript would be
allowed to add whatever additional methods ECMAScript has added since
WebIDL and FooSpec referencing WebIDL were published. Without a
referenceable thing, I don't see a way for WebIDL to do this. It's
fairly likely some implementation will miss a minor thing when
building the list. OTOH if ECMAScript is asked to maintain the list,
it's more likely they'll get it right (and reviewers of that spec are
more likely to catch omisions/errors).

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

-- 
Sent from my mobile device

Received on Thursday, 4 August 2011 03:09:44 UTC