- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 1 Aug 2011 10:24:03 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On Sun, Jul 31, 2011 at 4:50 PM, Cameron McCormack <cam@mcc.id.au> wrote: >> This discussion has come up a number of times and the conclusion is >> always the same. Several solutions have been proposed, some more >> workable than others, but unfortunately this thread doesn't mention >> any of them, nor does it bring up any new information which would help >> us get any closer to a conclusion. > > Here is a proposal (which I haven't thought deeply about yet): any interface > that supports indexed properties and which does not inherit from another > interface has Array.prototype as its prototype object's [[Prototype]] > instead of Object.prototype. Objects implementing these interfaces get the > magic length property (or inherit the non-magical accessor property if > that's what ES changes to have). It is then incumbent on the API designer > to define index setters/creators/deleters appropriately such that the > mutating Array methods make sense. Would this work? Is there a problem > with sparse Arrays at all? To me it still feels weird, and not javascripty, to have mutating functions on interfaces which are immutable, which is the majority of DOM interfaces with index getters/setters. Seems better to me to instead make up a new prototype object which contains all of Array's non-mutating methods and stick that object on the prototype chain of various classes. But I'm happy to stick the Array prototype on the prototype chain here if that's what the JS folks say is the right solution. But like Boris points out, I think we need to be able to modify this on a per-interfaces basis. Either through a opt-in or a opt-out. / Jonas
Received on Monday, 1 August 2011 17:25:00 UTC