- From: timeless <timeless@gmail.com>
- Date: Wed, 3 Aug 2011 23:09:04 -0400
- To: Cameron McCormack <cam@mcc.id.au>, Garrett Smith <dhtmlkitchen@gmail.com>, 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>
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