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

Re: Array-with-item in WebIDL

From: Joshua Bell <jsbell@google.com>
Date: Wed, 10 Jun 2015 10:19:24 -0700
Message-ID: <CAD649j7whyyLtmekxYwPwtpycqf+ufzrMwgw+HatPgG1FsskZg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Jun 10, 2015 at 10:02 AM, Tab Atkins Jr. <jackalmage@gmail.com>

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

DOMStringList is returned by a few attributes, so we need to sort out

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

There's also 'contains()' on DOMStringList which apparently can't be added
to Array.prototype, and gets significant (enough) usage. *sigh*

We've been discussing console warnings for both of these (on
DOMStringList). In the items() case, the warning would suggest [] instead.

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

Sounds like this is worth a try.

Is there pressure to come up with a way to express this in Web IDL before
we've shown it works? sequence_with_item_and_contains<> is pretty gruesome.

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

My guess: method names are easier to find in docs/reveal via autocomplete
than operators.
Received on Wednesday, 10 June 2015 17:19:52 UTC

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