Intentional: $.get & $.post may have the arguments passed in a way that the callback will not be the last argument

[joe@…]

John Resig has highlighted the importance of API consistency numerous times. As an example, he says that jQuery is set up to ALWAYS take the callback function as the last parameter.

However, $.get & $.post can both get a "dataType" parameter after the callback (all the way back to jQuery 1.0). Although this is not practically a bug (since this is intentional) it is against the API consistency theory.

[Rick Waldron]

So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

[anonymous]

Replying to rwaldron:

So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

Of course not. While some have called me mad, I've yet to be titled lunatic.

All I'm proposing is to add the option to pass the dataType before the success callback. Since dataType is always a string and the success callback is always, well, a function (and risking the ​Dunning–Kruger effect), this should be pretty easy to implement.

[anonymous]

Replying to joe@…:

John Resig has highlighted the importance of API consistency numerous times. As an example, he says that jQuery is set up to ALWAYS take the callback function as the last parameter.

However, $.get & $.post can both get a "dataType" parameter after the callback (all the way back to jQuery 1.0). Although this is not practically a bug (since this is intentional) it is against the API consistency theory.

Here's my ​proposed fix:

 // allow for callback to be passed in as last argument
if ( jQuery.isFunction(type) ) {
   var tempType = callback;
   callback = type;
   type = tempType;
}

[Rick Waldron]

As long as your content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

[anonymous]

Replying to rwaldron:

As long as you're content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

I don't understand what you're trying to say. jQuery does support incorrect content-type headers (by setting the dataTpe), and the API should be consistent with the rest of jQuery.

Are you proposing to get rid of the dataType argument altogether?

[Rick Waldron]

certainly not... I just think this is a completely unnecessary change.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[joe@…]

Replying to trac-o-bot:

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I truly believe that this should be addressed, since it's such an easy fix.

I've done all the work, and modified the above solution to take into account all possible scenarios ([url, data, dataType, success], [url, dataType, success] & [url, non-primitive dataType, success]).

I created a fiddle with the code, as well as a test for all variations possible (also showing that there's no regression): ​http://jsfiddle.net/afC5g/1/