This is basically what I am doing except I find Array#indexOf as it is pointless ... or better, something that should be fixed in the next version of ECMAScript.
Right now I am feature detecting the inconsistent behavior ... but a feature detection that will never possibly return true is also pointless ... thanks in any case :-) br On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller <[email protected]> wrote: > Please replace your use of indexOf in your collection implementations > instead. If indexOf is more efficient than one written in JS using > Object.is, then use the fast one when the argument is anything other > than NaN, 0, and -0. > > On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi > <[email protected]> wrote: > > Hello everybody, > > I am not sure about the status of this subject but I find quite > > inconsistent the fact we cannot trust Array#indexOf when it comes to NaN > ... > > I am updating my es6-collections shim accordingly with what Paul Millr > said: > > my shim does not consider NaN as a valid key, being unable to find a > match > > through indexOf, so each NaN key will result into a new one for both Map > and > > Set ( broken WeakMap too ) > > > > I wonder if in the next future Array#indexOf will use internally > Object.is > > to compare values or if I have to use my own function to loop over all > > values and do this kind of comparison. > > > > Any thought on this will be appreciated and apologies if this has been > > discussed already ( so a quick answer on "how it's going to be" would be > > more than enough ) > > > > Best Regards, > > Andrea Giammarchi > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
