Array.prototype.contains

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Array.prototype.contains

Eric Elliott
What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )

But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM. It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true

- Eric

Author, "Programming JavaScript Applications" (O'Reilly)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

David Bruant-5
Le 05/03/2014 09:24, Eric Elliott a écrit :
What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )
Let's try to add it to the next meeting agenda
https://github.com/tc39/agendas/pull/27

But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?


It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Eric Elliott
According to the thread:

> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson <erik.arvidsson at gmail.com>
> wrote:
> DOM4 added a new interface called DOMStringList for the sole reason
> that Array does not have contains. Before this the return type was an
> Array of Strings so we could use indexOf, map, forEach etc. Now that
> it is using a non Array we lost all of that.

> We (WebKit) used to return a true JS Array (created by JSC or V8).


Author, "Programming JavaScript Applications" (O'Reilly)


On Wed, Mar 5, 2014 at 2:07 AM, David Bruant <[hidden email]> wrote:
Le 05/03/2014 09:24, Eric Elliott a écrit :
What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )
Let's try to add it to the next meeting agenda
https://github.com/tc39/agendas/pull/27


But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?



It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

David


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Sebastian Zartner-2
In reply to this post by David Bruant-5
But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?

Why not? A use case would be to check whether a specific node is within a NodeList.
It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g.

.contains([1, 2, 3], [1, 3]) // true
.contains([1, 2, 3], [1, 4]) // false

Sebastian

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Boris Zbarsky
On 3/5/14 7:04 AM, Sebastian Zartner wrote:
> Why not? A use case would be to check whether a specific node is within
> a NodeList.

NodeLists don't have have Array.prototype on their proto chain in
browsers at the moment, and might never get there; there are compat
concerns.

I'd love to get rid of DOMStringList, though.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Rick Waldron
In reply to this post by David Bruant-5



On Wed, Mar 5, 2014 at 4:07 AM, David Bruant <[hidden email]> wrote:
Le 05/03/2014 09:24, Eric Elliott a écrit :
What ever happened to Array.prototype.contains? There's an old strawman for Array.prototype.has ( http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that references this thread: ( https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )
Let's try to add it to the next meeting agenda
https://github.com/tc39/agendas/pull/27


But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?

The forth-coming-still-in-design "Elements" class will inherit from Array.
 
Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Rick Waldron
In reply to this post by Sebastian Zartner-2



On Wed, Mar 5, 2014 at 7:04 AM, Sebastian Zartner <[hidden email]> wrote:
But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?

Why not? A use case would be to check whether a specific node is within a NodeList.
It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g.

.contains([1, 2, 3], [1, 3]) // true
.contains([1, 2, 3], [1, 4]) // false


String.prototype.contains already has a second parameter for "position" (similar to String.prototype.indexOf), for consistency an Array.prototype.contains should have the same second "fromIndex" parameter as Array.prototype.indexOf.

Rick



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Array.prototype.contains

Domenic Denicola-2

Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`.



From: es-discuss <[hidden email]> on behalf of Rick Waldron <[hidden email]>
Sent: Wednesday, March 05, 2014 11:11
To: Sebastian Zartner
Cc: es-discuss
Subject: Re: Array.prototype.contains
 



On Wed, Mar 5, 2014 at 7:04 AM, Sebastian Zartner <[hidden email]> wrote:
But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?

Why not? A use case would be to check whether a specific node is within a NodeList.
It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g.

.contains([1, 2, 3], [1, 3]) // true
.contains([1, 2, 3], [1, 4]) // false


String.prototype.contains already has a second parameter for "position" (similar to String.prototype.indexOf), for consistency an Array.prototype.contains should have the same second "fromIndex" parameter as Array.prototype.indexOf.

Rick



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Rick Waldron



On Wed, Mar 5, 2014 at 11:19 AM, Domenic Denicola <[hidden email]> wrote:

Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`.

Now that you mention it, I completely agree.

Rick
 



From: es-discuss <[hidden email]> on behalf of Rick Waldron <[hidden email]>
Sent: Wednesday, March 05, 2014 11:11
To: Sebastian Zartner
Cc: es-discuss
Subject: Re: Array.prototype.contains
 



On Wed, Mar 5, 2014 at 7:04 AM, Sebastian Zartner <[hidden email]> wrote:
But it seems the thread fizzled out a couple years ago, and Array.prototype.contains didn't seem to make its way into ES6. That seems odd, since we do have String.prototype.contains, and it seemed like it was desirable for DOM.
The DOM won't inherit from it directly, shall it?

Why not? A use case would be to check whether a specific node is within a NodeList.
It's also a standard utility function in several libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true
.indexOf === -1 works today for this use case and will continue to.
I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of .contains() though.

While .indexOf() just gets you the index of one item, .contains() could even be extended to allow to check whether an array contains several items. E.g.

.contains([1, 2, 3], [1, 3]) // true
.contains([1, 2, 3], [1, 4]) // false


String.prototype.contains already has a second parameter for "position" (similar to String.prototype.indexOf), for consistency an Array.prototype.contains should have the same second "fromIndex" parameter as Array.prototype.indexOf.

Rick




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

C. Scott Ananian
Hmm:
```js
s = new Set(['a','b','c']);
s.has('a'); // true
s.has('ab'); // false

s = "abc";
s.contains("a"); // true
s.contains("ab"); // true
s.contains("ab", 1); // false

s = [ 'a', 'b', 'c' ];
s.has('a'); // true
s.has('ab'); // false

s.contains('a'); // true
s.contains('b', 1); // false? like String#contains
// what sebastian wants?
s.contains('a', 'b'); // true?
s.contains(...new Set(['a','b'])); // if the above works, so does this

s.has(...new Set(['a','b'])); // better?
```
 --scott
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Mathias Bynens
In reply to this post by Domenic Denicola-2
On 5 Mar 2014, at 17:19, Domenic Denicola <[hidden email]> wrote:

> Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`.

But then DOM4 `DOMStringList` would still have its own `contains` _and_ the `has` it inherits from `Array.prototype`. That seems confusing, no?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Anne van Kesteren
In reply to this post by Domenic Denicola-2
On Wed, Mar 5, 2014 at 11:19 PM, Domenic Denicola
<[hidden email]> wrote:
> Personally I think the more useful model to follow than
> `String.prototype.contains` is `Set.prototype.has`.

That would not allow us to kill DOMStringList.


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Array.prototype.contains

Domenic Denicola-2
> That would not allow us to kill DOMStringList.

Can we get more background on DOMStringList? It seems unlikely that you could get away with replacing a string-only type, which, from the specs I can find, seems to be immutable and have an additional index() method, with an actual mutable any-type-containing array.

It's not in http://dom.spec.whatwg.org (except as "don't implement this") and https://developer.mozilla.org/en-US/docs/Web/API/DOMStringList implies it's not implemented in Mozilla, and only used by an obscure property.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Boris Zbarsky
On 3/6/14 3:58 PM, Domenic Denicola wrote:
>> That would not allow us to kill DOMStringList.
>
> Can we get more background on DOMStringList?

Sure.  It's used in the following places in Gecko, as far as I can tell:

1) document.styleSheetSets.
2) Microdata API.
3) Various places in indexeddb.
4) The DataTransfer API.
5) Some sort of offline resource list API that's not part of any
standard I can find.

#1 is not implemented by anyone but Gecko, and the spec is claiming it's
a DOMString[], which no on implements at all.

#2 is likewise not implemented by anyone but Gecko at this point, and
the spec likewise claims DOMString[] (which again no one implements).

For #3 I've heard Jonas claim he'd like to just moving ES arrays there.

#4 is specced as a DOMString[], which again no one implements.

I don't know offhand what other UAs do for #3 and #4.

> It seems unlikely that you could get away with replacing a string-only type, which, from the specs I can find, seems to be immutable and have an additional index() method

DOMStringList in Gecko does not have an index() method.  Did you mean
item()?

Whether it's OK to replace with a mutable and any-type-containing thing
is an interesting philosophical question.  Some of the above use cases
may be OK with using a frozen array, for example, or not care if the
page changes it around, since the browser doesn't plan to use it itself.

But yes, it's not a priori obvious that one can replace the other.

> https://developer.mozilla.org/en-US/docs/Web/API/DOMStringList implies it's not implemented in Mozilla

That page was a bald-faced lie.  Note the "in need of a technical
review" bit.  ;)  I've removed the completely bogus part for now.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Array.prototype.contains

Domenic Denicola-2
Thanks very much Boris. It sounds like there isn't much of a cross-browser or standardized story on where `DOMStringList`, with its `contains()` and `item()` methods (yeah, I meant `item`) shows up.

I'd be curious where it shows up in Blink, IE, and WebKit codebases. If the intersection is small enough, such that no web developers are relying on `contains()` and `item()` being present on certain APIs, then maybe `DOMStringList` can be killed and replaced with arrays and/or frozen arrays, without adding `contains()`/`item()` to `Array.prototype`...
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Brendan Eich-3
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

> 1) document.styleSheetSets.
> 2) Microdata API.
> 3) Various places in indexeddb.
> 4) The DataTransfer API.
> 5) Some sort of offline resource list API that's not part of any
> standard I can find.
>
> #1 is not implemented by anyone but Gecko, and the spec is claiming
> it's a DOMString[], which no on implements at all.
>
> #2 is likewise not implemented by anyone but Gecko at this point, and
> the spec likewise claims DOMString[] (which again no one implements).
>
> For #3 I've heard Jonas claim he'd like to just moving ES arrays there.
>
> #4 is specced as a DOMString[], which again no one implements.

What's with all the "no one implements" (including #3) stuff in specs?
Are the specs new? Are we in a situation (even in #3, _pace_ Jonas)
where the specs should be changed to reflect reality?

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Boris Zbarsky
On 3/6/14 4:49 PM, Brendan Eich wrote:
> What's with all the "no one implements" (including #3) stuff in specs?

IDL Arrays in general are not implemented by anyone that I know of (and
possibly ever).  They were a new concept added in WebIDL that hasn't
really caught on with implementations.  In Gecko's case that was because
we never got around to it, and it was simpler to use the infrastructure
we needed to create anyway or already had for "indexed getters" (c.f.
DOMStringList, NodeList, etc) than to create a bunch of new
infrastructure for IDL Arrays.

And then people realized that in some ways IDL Arrays are an attractive
nuisance even if they were implemented, which made the priority on
implementing them even less.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 has discussion
that's worth reading, if people haven't already, about the various use
cases that arise for arrays and arraylikes and how to best solve them.

> Are the specs new?

Somewhat.

> Are we in a situation (even in #3, _pace_ Jonas)
> where the specs should be changed to reflect reality?

Yes.  Need to figure out what reality is or should be, first.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Joshua Bell-3
FWIW, Blink uses DOMStringList only in IndexedDB and apparently in Location.ancestorOrigins



On Thu, Mar 6, 2014 at 1:59 PM, Boris Zbarsky <[hidden email]> wrote:
On 3/6/14 4:49 PM, Brendan Eich wrote:
What's with all the "no one implements" (including #3) stuff in specs?

IDL Arrays in general are not implemented by anyone that I know of (and possibly ever).  They were a new concept added in WebIDL that hasn't really caught on with implementations.  In Gecko's case that was because we never got around to it, and it was simpler to use the infrastructure we needed to create anyway or already had for "indexed getters" (c.f. DOMStringList, NodeList, etc) than to create a bunch of new infrastructure for IDL Arrays.

And then people realized that in some ways IDL Arrays are an attractive nuisance even if they were implemented, which made the priority on implementing them even less.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 has discussion that's worth reading, if people haven't already, about the various use cases that arise for arrays and arraylikes and how to best solve them.

Are the specs new?

Somewhat.


Are we in a situation (even in #3, _pace_ Jonas)
where the specs should be changed to reflect reality?

Yes.  Need to figure out what reality is or should be, first.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

C. Scott Ananian
And don't forget the related `DOMTokenList`, which is in
Element.classList and thus used by everyone always.

The `contains` and `item` methods are in `DOMTokenList`, so they
probably shouldn't be removed from `DOMStringList`.  But I don't think
anyone was seriously proposing that, just that `DOMStringList` would
be a subclass of `Array`...  (and maybe `DOMTokenList` would also be
related to `Array`?)
 --scott
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Array.prototype.contains

Claude Pache

Le 7 mars 2014 à 00:45, C. Scott Ananian <[hidden email]> a écrit :

> And don't forget the related `DOMTokenList`, which is in
> Element.classList and thus used by everyone always.
>

Indeed, and there is also the (less known) `htmlFor` property of  the <output> element, which is precisely a `DOMSettableTokenList`.

Since arraylike interfaces from the DOM uses `.contains()`, for the sake of consistency, the corresponding method on `Array.prototype` ought to be named `.contains()`. Sets are quite different from Arrays, so it is less important to have the same naming scheme as Sets than as all other arraylikes. (And another weaker reason to prefer `.contains()`: Maps and WeakMaps uses `.has()` for *keys*, and here we are talking about the *values* of an Array.)

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12