function isArray(array){
return array? !!array.push : false;
}



function isArray(array){
try{ return !!array.push; }catch(e){ return false; }
}


I’ve tested this and it works fine as far as I see.

function isArray(object) {
if (object instanceof Array) return true;
return Object.prototype.toString.call(object) === ‘[object Array]‘;
}

That way you’re covering your bases pretty well.

@kangax: There is a problem with using Array.prototype.toString.call(obj) with arrays with several items i.e. 1000 with firefox 3.x running it over 50000 iterations is unacceptably slow i.e. 15-20 secs.

The idea is sound but toString is the wrong function to use. I did some experimenting and I came up with this function drawing from several other peoples Ideas.

function isArray(obj) {
if (obj instanceof Array) {
return true;
} else {
try {
if (obj.length > 0 && Array.prototype.slice.call(obj,0,1)[0] === obj[0]) {
return true;
} else {
if (Array.prototype.slice.call(obj,0,1).length === obj.length) {
return true;
}
}
}catch (e) {}
return false;
}
}

This function is lightning fast for regular arrays or sub classed arrays on pages without frames as it is just a obj instance of Array call. For pages with frames it is a single call to Array.prototype.splice.call(obj,0,1) which is quick regardless of array length if the array has elements it makes sure the element it received is equal to the first item in the array, if it is an empty array it compares the length of Array.prototype.splice.call(obj,0,1) with the original obj.length both of which should be zero.

for 50000 iterations the timing was
instanceof: 19ms
isarrayRegularArray: 48ms
isarrayFrameArray: 245ms

So for objects that are instances of Array according to Javascript the function call is approximately 2.5 times slower than the builtin instanceof command. for arrays in separate frames it is approximately 12-13 times slower. most importantly Array size is also not a contributing factor ran the tests with a 1000 element array and a 10000 element array with no time difference.

@mjuhl: This suffers from the same issues as the instanceof method and additionally its more obtrusive, since it adds an extra useless property to the Array prototype. Also, the ternary operator is redundant (return !!(o && o.isArray); would suffice), and so is the conversion to boolean (since __isArray__ is already boolean).

Array.prototype.__isArray__ = true;
function isArray(o) {
return (o && o.__isArray__) ? !!o.__isArray__ : false;
};

alert(isArray([])+ ‘,’ + isArray({})+ ‘,’ + isArray(null));
// true,false,false

Interesting. My results are actually less dramatic (FF3.0.5 on Mac OSX) and seem to be negligible even under `50000` iterations. The difference is still there, of course.


var arr = [1, 'a', /foo/, NaN];
var LIM = 50000;

instanceof: 86ms
constructor: 108ms
[[Class]]: 131ms


Regarding “sub-arrays”, it should be trivial to special-case `isArray` to account for them. E.g.:


function Sub(){};
Sub.prototype = new Array();
var sub = new Sub();
sub instanceof Array; // true

isArray(sub);


You could of course change it to account for arbitrary-level “sub-arrays” (i.e. check up the prototype chain till reaching `null`)
I agree that this “workaround” is not “ideal”. Unfortunately, so is our current state of JS/DOM affairs : )

AFAIK, `Object.prototype.toString` is generic. In case of “emergency”, it is possible to “restore” it from the “clean” context of newly created frame (in clients which support frame creation/inspection):


Object.prototype.toString = (function(){
var root = (document.body || document.documentElement);
var el = document.createElement('iframe');
root.appendChild(el);
var s = window.frames[window.frames.length-1].Object.prototype.toString;
root.removeChild(el);
return s;
})();


Ok not slow as a function in general, but 20 times slower compared to the instanceof way.

Perhaps a solution would be to check the length of window.frames and choose the method according to that, but then we’d still face issues with:
1. Scripted new windows.
2. Sublclassed arrays. I find it ok that the new method returns false for them, but it should be consistent. It should return either always true, or always false for subclassed arrays. It can’t return true for them and if you add a frame suddenly false for them, or true if the suclassed array belongs to the current window and false if it belongs to a frame!

Combining both methods with the || operator also suffers from problem 2, and would be even slower when the object is NOT an array.

A method like isArray should be lightning fast since it’s used very often. So even though I admire the brilliance of this solution, I’m still uncertain whether to use it.

(end even if I prefere this one, I am sure performances are not the same of the other toString trick)

There’s an easier way, really : )

function isArray(o) {
try {
Array.prototype.toString.call(o);
return true;
} catch(e) { }
return false;
};
isArray([]); //true
isArray(); // false

See http://github.com/kangax/protolicious/tree/master/object.extensions.js#L1 for explanation

The main downside I see in retrieving [[Class]] value is that we don’t know how host objects implement it. They could be designed to throw error when [[Class]] lookup occurs (just like IE is known to throw for internal [[Get]] of certain objects – notably AcitveX components), or even collide with spec-defined values for native objects – “Array”, “Function”, etc. We can either do extensive testing or just deal with the fact that host objects’ behavior can never be relied upon.

function isArray(Object){
var result = false;
try{new Object.constructor(Math.pow(2, 32))}catch(e){result=/Array/.test(e.message)};
return result;
};

alert(isArray([]));

Just because `[[Class]]` of certain host objects is represented as “HTMLDivElement” in a browser doesn’t really mean that that browser supports, say, `Element.prototype` inheritance, and/or have `.constructor` referencing globally declared `HTMLDivElement` constructor, etc. : )

Specification happens to be silent in this regard.

I assume that’s because “Stack” is indeed an Object object. I’m not sure what kind of implementation you’re talking about, but [[Class]] value is not inherited via [[Prototype]], afaik.