Array.prototype.contains

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Jul 24 18:05:09 PDT 2014


no, my concern is about having different results between .contains() and
.indexOf() in production code ... the NaN was the most obvious case/example
on how that could go deadly wrong.

if a.contains(v) i = a.indexOf(v); now enjoy inconsistency with what you
were expecting ^_^

Just to clarify, I am not saying .contains() should not exist in first
place, I am saying we should fix bloody indexOf too ... we can easily fix
broken old gotchas and polyfill them on top instead of mixing up methods
used for potentially similar intent but absolutely not replaceable for the
same ... if tomorrow everyone will swap from -1 < a.indexOf() to
a.contains() maybe that's desired but surely not the same thing, and vice
versa when the contained index is needed.

Best Regards



On Thu, Jul 24, 2014 at 11:30 AM, Garrett Smith <dhtmlkitchen at gmail.com>
wrote:

> On 7/24/14, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> > What is this about? Not an answer nor a solution to what I've said...
> > Just think that NaN is rarely an explicit value, rather something
> > potentially generated at runtime. Would
> > you .some(Number.isNAN.bind(Number)) all the Arrays? I don't think so,
> > at least I wouldn't
> >
>
> It looked like you were trying to determine if a finite number is in
> an array. Is that right? That answer to how to do that would be:
>
> Number.isFinite(v) && arr.indexOf(v) != -1;
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140724/2e5de9aa/attachment.html>


More information about the es-discuss mailing list