Javascript – Is the capability to overwrite functions in JavaScript strength or weakness

javascript

I recently came across the following code (from liferay.js) when I was working with Liferay:

....
if (!Liferay._ajaxOld) {
    Liferay._ajaxOld = jQuery.ajax;
}

if (Liferay._ajaxOld) {
    jQuery.ajax = function(options) {
        if (Liferay.Util) {
            options.url = Liferay.Util.getURLWithSessionId(options.url);
        }
        return Liferay._ajaxOld(options);
    };
}
....

As you can see, the code above overwrites the function "jQuery.ajax" to modify "options.url". One may say this is a strength of the language since we can easily overwrite and customize existing functions.

However, I would imagine this capability can easily lead to a problem. For instance, my code can overwrite the same function "jQuery.ajax" to modify "options.url" differently from the code above. As a result, any code that expect the behavior defined by "liferay.js" may no longer function as expected.

I see this as a weakness of the language as it does not provide proper encapsulation.
What are the consensus about this feature/capability of the language in the field?

Best Answer

I think it really depends on who you ask. Javascript is by no means a perfect language, but just like abstraction of private variables, this may be a good or bad thing depending on the situtation.

If you're using a library and want to overwrite a function, then it's a good thing, if you're the author of a library or function, and someone uses your code in a way you do not intend, then it is not.

Related Solutions

Javascript – Self-referencing anonymous closures: is JavaScript incomplete

I suppose everything is a matter of taste, but does this not look like a kludge, when all you want is a private namespace? Couldn't JavaScript implement packages and proper classes?

Most of the comments are argue against the myth that "prototypes are poor man's classes", so I'll just repeat that prototype-based OO isn't inferior in any way to class-based OO.

The other point "a kludge when all you want it a private namespace". You might be surprised to know that Scheme uses the exact same kludge to define scopes. That didn't stop from becoming the archetypal example of lexical scoping well done.

Of course, in Scheme, the 'kludge' is hidden behind macros....

JavaScript – Managing Callback Nesting in Programming

Just because you can use anonymous functions (lambdas) for this kind of construct doesn't mean you have to. Just like it's good practice to pull complex value construction syntax out of a function call and into its own variable, you can do the same with your function literals. Observe:

// Your example:
$(".foo").animate({
    top: 0,
}, {
    callback: function () {
        $.ajax({
            url: 'ajax.php',
        }, {
            callback: function () { ... }
        });
    }
});

// Can be rewritten as:
var animateProps = { top: 0 };
var animateCallback = function() {
    var ajaxProps = { url: 'ajax.php'; }
    var ajaxCallback = function () { ... }
    $.ajax(ajaxProps, {callback: ajaxCallback});
};
$(".foo").animate(animateProps, {callback: animateCallback});

// Or even, depending on what you do inside the ajax callback:
var animateProps = { top: 0 };
var ajaxProps = { url: 'ajax.php'; }
var ajaxCallback = function () { ... }
var animateCallback = function() {
    $.ajax(ajaxProps, {callback: ajaxCallback});
};
$(".foo").animate(animateProps, {callback: animateCallback});

And all the ugly nested syntax is gone!

Note, however, that the nested-anonymous-function style isn't all that bad; after all, if your function calls follow a logical structure, then so will the function call nestings. Example:

doAsyncSomething(
    function(successData){
        alert("All is well!");
    },
    function(errorMessage){
        alert("Oh no! Something went wrong! Namely: " + errorMessage);
    });

In this example, the code nesting follows the logical structure quite nicely.

Related Topic