We could/should add a check for type === "string" here: https://github.com/jquery/jquery/blob/master/src/core.js#L495 which would make jQuery's "array-like" checking future-friendly with emerging language additions, ie. String.prototype.@@iterator, Array.from(string), etc.

Before I go ahead with this, I want Richard to sign off on my rationale above

isArrayLike is a private function, and as far as I can tell never receives string input from valid public calls. So my default position is to oppose changes until seeing a demonstration warranting such.

Replying to [comment:3 gibson042]:

isArrayLike is a private function, and as far as I can tell never receives string input from valid public calls. So my default position is to oppose changes until seeing a demonstration warranting such.

Good call and agreed.

Replying to [comment:4 rwaldron]:

Replying to [comment:3 gibson042]: > isArrayLike is a private function, and as far as I can tell never receives string input from valid public calls. So my default position is to oppose changes until seeing a demonstration warranting such.

It means whenever you call $.map or other functions that use isArrayLike you get a horrible error message back. The extra overhead of checking for string is surely negligible for a better return value?

Replying to [comment:5 Nigel]:

Replying to [comment:4 rwaldron]: > Replying to [comment:3 gibson042]: > > isArrayLike is a private function, and as far as I can tell never receives string input from valid public calls. So my default position is to oppose changes until seeing a demonstration warranting such. > It means whenever you call $.map or other functions that use isArrayLike you get a horrible error message back. The extra overhead of checking for string is surely negligible for a better return value?

Could you please provide a test case using public jQuery API? You could use jsfiddle or similar service for that.

It means whenever you call $.map or other functions that use isArrayLike you get a horrible error message back.

There are no guarantees what you'll get back when you call an API method with incorrect arguments.

Replying to [comment:6 markelog]:

Could you please provide a test case using public jQuery API? You could use jsfiddle or similar service for that.

just call $.map with a string: http://jsfiddle.net/aH4mU/

Replying to [comment:7 dmethvin]:

> It means whenever you call $.map or other functions that use isArrayLike you get a horrible error message back. There are no guarantees what you'll get back when you call an API method with incorrect arguments.

isArrayLike, even as a private function, should (IMHO) not throw an exception if passed a non array - it should return false. Surely the whole point of having it is to check if it is array like and do something else if not?

Though in its current form it probably blows up if the argument doesn't have a length property anyway.

Sorry - make that http://jsfiddle.net/aH4mU/1/

Replying to [comment:8 anonymous]:

just call $.map with a string: http://jsfiddle.net/aH4mU/

jQuery.map accepts arrays and objects, not strings.

Replying to [comment:9 Nigel]:

isArrayLike, even as a private function, should (IMHO) not throw an exception if passed a non array - it should return false. Surely the whole point of having it is to check if it is array like and do something else if not?

The whole point of having it is to identify those objects that should be iterated over by numeric index, generally to differentiate them from objects that should be iterated over with for...in loops. We take pains to ''avoid'' passing in strings, and if you circumvent that by calling jQuery methods with invalid input, then (as [comment:7 dmethvin] said) "There are no guarantees what you'll get back".

And although we'd never add code to guarantee it, I consider throwing exceptions when a call steps outside the bounds of our documented API to be ''better'' behavior than silently propagating misconceptions.