Question

I’m just wondering if anyone knows why $.map and $.fn.map pass arguments in flipped order from one-another. Is there a valid reason (e.g. ECMA specs somewhere) for it or was it just a poorly-planned API that is now impossible to fix due to the amount of code relying on jQuery?

$.map([ 'a', 'b', 'c' ], function(){ console.log(arguments); })
// ['a', 0], ['b', 1], ['c', 2]

$.fn.map.call([ 'a', 'b', 'c' ], function(){ console.log(arguments); })
// [0, 'a'], [1, 'b'], [2, 'c']

.each doesn’t act like this

Answer 1

Here’s my completely and entirely speculative “answer”.

jQuery.each(), .each() and jQuery.map() were all present in version 1.

.map() was added in 1.2.

My guess is that they simply didn’t give consideration to having the each methods follow the forEach in the spec. (What was the status of ES 5 at that time anyway?) But for some reason they did follow closer to the spec for $.map(). (Maybe its original intention was for primarily internal use as well.)

So when jQuery 1.2 came along, they decided it would be nice to have a .map() method.

So the question they faced was to have .map() follow $.each() and .each(), or follow $.map().

Since .each() in particular had already been implemented as callable against a jQuery object, they felt that it would cause less confusion to have .map() follow .each() than to follow $.map(), which is most certainly not used as much.

Looking at the source for the .map() method vs the .each() method, you can see that .map() requires an intermediate function in order to flip around the arguments and set the this value. Somehow I doubt that they would have wanted to do that if they had it all planned out in advance.

Again, this is complete and utter speculation, but I wouldn’t be surprised if it happened something like that.

Take it or leave it. ;o)