Is the "old load method" defined anywhere? I don't see it. It looks like if there is no old "load" method, and the first argument is a string, a TypeError should occur (as the result of performing a call operation on an undefined value).
Have you considered moving some of the method to a separate function, e.g. from:
// Request the remote document
// [...]
to:
requestRemoteDocument( /* context args */ );
I also see that jQuery.ajax is a very long method, with a lot of conditional logic around the dataType.
I see: This is a workaround to an internal name collision of load. The workaround/solution you've employed seems to be creating very tight coupling between ajax.js, event.js, and build order.
The load method in ajax.js expects that there is a load method defined elsewhere (it is in event.js), that that other load method accepts non-string values and that it does not accept string values (because ajax.js' load takes that case). This is essentially a mutual exclusion between parameter type between two same-named methods of two modules.
The problems related to the name collision can be avoided by renaming ajax.js' load method to something that does not conflict, such as loadURL , makeRequest, etc. Why not do that?
Well, we've done it this way for almost 4 years now. The decision to overload the functionality of .load() to both event and ajax was made fairly early on. Much in the same way we overload .attr() (and don't have getAttr and setAttr).
This comment has been minimized.
Is the "old load method" defined anywhere? I don't see it. It looks like if there is no old "load" method, and the first argument is a string, a TypeError should occur (as the result of performing a call operation on an undefined value).
Have you considered moving some of the method to a separate function, e.g. from:
to:
I also see that jQuery.ajax is a very long method, with a lot of conditional logic around the
dataType.This comment has been minimized.
sorry, should be:
...if there is no "old load" method, and the first argument is not a string...
This comment has been minimized.
The "old load method" is in event.js, which is always compiled in before ajax.js.
This comment has been minimized.
I see: This is a workaround to an internal name collision of
load. The workaround/solution you've employed seems to be creating very tight coupling between ajax.js, event.js, and build order.The
loadmethod in ajax.js expects that there is aloadmethod defined elsewhere (it is in event.js), that that otherloadmethod accepts non-string values and that it does not accept string values (because ajax.js'loadtakes that case). This is essentially a mutual exclusion between parameter type between two same-named methods of two modules.The problems related to the name collision can be avoided by renaming ajax.js'
loadmethod to something that does not conflict, such asloadURL,makeRequest, etc. Why not do that?This comment has been minimized.
Well, we've done it this way for almost 4 years now. The decision to overload the functionality of .load() to both event and ajax was made fairly early on. Much in the same way we overload .attr() (and don't have getAttr and setAttr).