it doesn't in my case ... arrays are "sandboxed" so none can access them and set twice the same value ;-)
anyway, that was a proof of concept, not a fully implemented indexOf with strict comparison, apologies I should have specified that. br On Thu, Jun 14, 2012 at 2:25 PM, Herby Vojčík <[email protected]> wrote: > > > Andrea Giammarchi wrote: > >> just in case ... this is my internal function >> >> // var is = Object.is || properShim >> // var indexOf = [].indexOf || shortShim >> // var i; >> function betterIndexOf(value) { >> if (value != value || value === 0) { >> for (i = this.length; i-- && !is(this[i], value);); >> > > I always has the impression that indexOf is firstIndexOf not > lastIndexOf... sometimes it matters. > > Herby > > } else { >> i = indexOf.call(this, value); >> } >> return i; >> } >> >> maybe somebody else should implement something similar to avoid N >> Object.is(a, b) checks within the loop ... >> >> cheers >> >> On Thu, Jun 14, 2012 at 1:59 PM, Andrea Giammarchi >> <[email protected] >> <mailto:andrea.giammarchi@**gmail.com<[email protected]>>> >> wrote: >> >> 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] >> <mailto:[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] >> <mailto:andrea.giammarchi@**gmail.com<[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] <mailto:[email protected]**> >> >> > >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > >> >> >> >> -- >> Cheers, >> --MarkM >> >> >> >> >> ------------------------------**------------------------------** >> ------------ >> >> >> ______________________________**_________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
