Re: Array-with-item in WebIDL

On Thu, Jun 11, 2015 at 1:19 AM, Joshua Bell <jsbell@google.com> wrote:
> On Wed, Jun 10, 2015 at 10:02 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> 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
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

Agreed. I actually consider that a solved problem given the discussion
in the bug, but it needs to be put into the WebIDL spec.

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

Ugh. Indeed.

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

Yeah, same here, but no one has taken the time to add those.
Deprecating .item() and/or .contains() is something we could do
independently of a move to sequence_with_item<...>.

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

One thing to keep in mind is what do we want Array.isArray() to return
for one of these objects? My understanding is that it only returns
true for "real" Arrays and returns false for Array subclasses. Is that
desirable here?

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

I'd not block on WebIDL syntax. And given that this is for legacy
APIs, I personally think that even sequence_with_item_and_contains is
ok.

/ Jonas

Received on Thursday, 11 June 2015 00:37:01 UTC