Domenic Denicola-2 wrote
> Personally I think the more useful model to follow than
> `String.prototype.contains` is `Set.prototype.has`.

API wise, arrays have much more in common with strings than with sets.

Thinking ES5, they're both array-likes, set isn't. They share `length`
property,  their values can be accessed through indexes arr[0], str[0], they
share few method names (`indexOf`, `lastIndexOf`), and all non destructive
array methods can be successfully executed on strings, while they won't work
with sets.

I think it would be more appropriate to stick with `arr.contains` especially
that we already have `arr.indexOf` and `str.indexOf`, and both `indexOf` and
`contains` share same signature.

`arr.has` could be fine, if we also rename `str.contains` to `str.has`.







--
View this message in context: http://mozilla.6506.n7.nabble.com/Array-prototype-contains-tp309926p310234.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.

Domenic Denicola-2 wrote
> Personally I think the more useful model to follow than
> `String.prototype.contains` is `Set.prototype.has`.

API wise, arrays have much more in common with strings than with sets.

Thinking ES5, they're both array-likes, set isn't. They share `length`
property,  their values can be accessed through indexes arr[0], str[0], they
share few method names (`indexOf`, `lastIndexOf`), and all non destructive
array methods can be successfully executed on strings, while they won't work
with sets.

I think it would be more appropriate to stick with `arr.contains` especially
that we already have `arr.indexOf` and `str.indexOf`, and both `indexOf` and
`contains` share same signature.

`arr.has` could be fine, if we also rename `str.contains` to `str.has`.