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 <dhtmlkitc...@gmail.com> wrote: > On 7/24/14, Andrea Giammarchi <andrea.giammar...@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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
