W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2015

Re: Array-with-item in WebIDL

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 10 Jun 2015 10:02:51 -0700
Message-ID: <CAAWBYDB0u7=Ln4nXXdmZBaf=dj5kpvfbvUwHwjXjTr8GozJv0A@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Jun 9, 2015 at 9:45 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> As you may know, we have a number of types, at least DOMStringList,
> FileList and DOMRectList which are essentially JS Array objects.
> Except that they now are DOM objects and so lack a bunch of the useful
> functions on the Array prototype. This often cause developers to do
> ugly hacks like
> var realArray = Array.prototype.slice.call(domObject, 0);
> Generally speaking, this is fixable by changing DOMStringList into
> sequence<DOMString> in the webidl. This would cause these functions to
> return real JS Arrays instead.
> The only thing preventing us from doing this is that the DOM classes
> for historical reasons have a .item() function on them. This .item()
> function is redundant and most developers simply use domObject[n]
> rather than domObject.item(n). Sadly the .item() functions seem used
> enough that switching to Arrays isn't web compatible.
> I was thinking we could introduce a sequence_with_item<...> type in
> WebIDL. This would simply map to a real Array object, but one which
> has a .item function added to it. Either by adding a .item function on
> the returned object itself, or by making the return object have a
> different prototype, but otherwise be a normal Array.
> Obviously an alternative is to just leave things as status-quo.

I would prefer we not status-quo on this.  As an author, the constant
need to wrap return values in [].slice.call() is frustrating and
tiring.  Array subclass seems like the way to go.

(Also I want to find these people that are using .item() and shake
them while shouting "WHYYYYYYY?".)

Received on Wednesday, 10 June 2015 17:03:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC