W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: Non-constructible constructors and Arrays

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 01 Aug 2011 11:50:01 +1200
Message-ID: <4E35EA29.9020408@mcc.id.au>
To: Jonas Sicking <jonas@sicking.cc>
CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On 29/07/11 2:25 PM, Jonas Sicking wrote:
> I'm very aware how the Array functions are defined. The problem is
> that there aren't any reasonable defaults we could provide for
> NodeList's [[Put]] operations simply due to what a NodeList
> represents.
>
> The only reasonable thing we could do is to make all mutating
> operations throw, which frankly would be a pretty strange API. I.e.
> all NodeLists would have whole host of operations like .push and
> .shift which always would throw. It would seem much better if those
> operations weren't there.

I actually don't think it is so terrible that a read only NodeList throw 
when calling the mutating methods from Array.

So currently through index setters/etc. we would support defining 
behaviour to make the Array mutation methods make sense if you use 
[].pop.call(obj) for example.  The only thing missing is having 
Array.prototype in the prototype chain.

> 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?
Received on Sunday, 31 July 2011 23:50:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC