Re: Array-with-item in WebIDL

Yes.

We tried to add contains to Array.prototype for ES7 but it turns out
to break the web.

`item` seem even more problematic but it would be interesting to see
what you would find out if you try.

On Tue, Jun 16, 2015 at 2:50 PM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
> Perhaps this is heretical, but has anyone considered adding "item" and/or "contains" to the native Array.prototype object in ES? If this is indeed the web-compat blocker for dropping NodeList use in various DOM APIs, I'd like to see if anyone could support this.
>
> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Wednesday, June 10, 2015 5:36 PM
> To: Joshua Bell
> Cc: Tab Atkins Jr.; public-script-coord@w3.org
> Subject: 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
>



-- 
erik

Received on Tuesday, 16 June 2015 21:57:55 UTC