-
-
Save sebastien-p/1042874 to your computer and use it in GitHub Desktop.
[].some || (Array.prototype.some = function ( | |
a, // callback | |
b, // thisObject | |
c, // 'this' shortcut | |
d // placeholder for iterator/result | |
){ | |
for ( | |
c = this, | |
d = c.length; | |
d--; | |
) | |
if (d in c && a.call(b, c[d], d, c)) break; | |
return !!~d // d's value can be 0 to X (if callback returns true) or -1 | |
}) |
[].some||(Array.prototype.some=function(a,b,c,d){for(c=this,d=c.length;d--;)if(d in c&&a.call(b,c[d],d,c))break;return!!~d}) |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
Version 2, December 2004 | |
Copyright (C) 2011 Sebastien P. https://twitter.com/#!/_sebastienp | |
Everyone is permitted to copy and distribute verbatim or modified | |
copies of this license document, and changing it is allowed as long | |
as the name is changed. | |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | |
0. You just DO WHAT THE FUCK YOU WANT TO. |
{ | |
"name": "Array.prototype.some", | |
"description": "ES5 Array.prototype.some polyfill", | |
"keywords": [ | |
"ES5", | |
"Array", | |
"some", | |
"polyfill" | |
] | |
} |
<!DOCTYPE html> | |
<title>Foo</title> | |
<div>Expected value: <b>false</b></div> | |
<div>Actual value: <b id="ret"></b></div> | |
<script> | |
Array.prototype.some=function(a,b,c,d){for(c=this,d=c.length;d--;)if(d in c&&a.call(b,c[d],d,c))break;return!!~d} | |
document.getElementById("ret").innerHTML = ["140","bytes","rocks"].some(function(a){return a==="sucks"}) | |
</script> |
@jdalton : is it just because of the "don't care about the holes in the array" thing or because of the reverse loop (or maybe both) ?
@sebastien-p Some of the things I sport are the length
is computed incorrectly, the iteration order is reversed, there is a lack of sparse array support and there is no error thrown for if this
is null
or undefined
.
@jdalton : what is the problem with the length computation ? I'm not sure but I think the iteration order shouldn't be an issue here, is it ? Same when this
is null
or undefined
, I think c[d]
should throw an error. PS : sorry for my english.
what is the problem with the length computation ?
It should be d = c.length >>> 0
this basically a way to reproduce - ToUint32.
I'm not sure but I think the iteration order shouldn't be an issue here, is it ?
You start from right-to-left instead of left-to-right which is inconsistent with native Array#some
and callbacks requiring a specific order will be mixed up.
Same when this is null or undefined, I think c[d] should throw an error.
True it will error and will still be a TypeError
but it's more hacky than correct. The check should be done before the loop so the error won't contain a message about invalid property access.
@jdalton : you said "it's more hacky than correct", you're right, but I think it's kinda the whole point of 140bytes.
Is function(a,b){for(var c=this,d=-1,e=c.length>>>0;++d<e;)if(d in c&&a.call(b,c[d],d,c))break;return d<e}
better ?
Is function(a,b){for(var c=this,d=-1,e=c.length>>>0;++d<e;)if(d in c&&a.call(b,c[d],d,c))break;return d<e} better ?
Yap better.
Though I don't think ES5 fallbacks are the best choice for code golf in general because things should be really tight and follow spec as these methods are added to native prototypes.
This fallback is not ES5 compliant.
Also browsers like Chrome have a bug where
Array.prototype.some = [].some
will causeArray#some
to become enumerable.