-
-
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> |
This fallback is not ES5 compliant.
Also browsers like Chrome have a bug where Array.prototype.some = [].some
will cause Array#some
to become enumerable.
@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.
@jed : my bad, I misunderstood the
thisObject
thing, going to correct this.Edit : there it is, 114 bytes !