If you are a SharePoint developer, or do some general .NET development, you probably work with overloading methods. Using the same name you can define multiple variants of the same method by specifying a different set of parameters. As SharePoint 2010 contains a large piece of very powerful API in the JavaScript: both for communicating with the SharePoint platform (also known as the SharePoint Client Object Model) and manipulating the UI, the odds are high that you will sooner or later start using JavaScript more and will extend the functionality provided by SharePoint to meet your needs. While overloading might seem very straight forward, there is one thing that you need to remember while working with JavaScript.
…and that thing is: JavaScript does not support overloading!
Let’s have a look at the following example:
function addNumbers(n1, n2, n3) {
return n1 + n2 + n3;
}
function addNumbers(n1, n2) {
return n1 + n2;
}
var sum = addNumbers(1, 2, 3);
If overloading worked correctly the value of sum would be 6. However, as JavaScript doesn’t support overloading, the value of sum is something else.
JavaScript supports overriding not overloading, meaning, that if you define two functions with the same name, the last one defined will override the previously defined version and every time a call will be made to the function, the last defined one will get executed. Looking at the above example, the value of sum will be equal 3 instead of 6.
Why does the above matter? Imagine that you want to extend the SharePoint API with some function like for example one that allows you to display a message in the status bar and set the color of that message. If you would include such function in the SP.UI.Status namespace, just to make using it more intuitive, you would have a risk of someone else, perhaps even the SharePoint team, to overwrite your function with another implementation which might break your code. So the question is, while extending the SharePoint JavaScript API: should you extend the default namespaces or include the methods in one that you own yourself?
January 30th, 2010 at 11:32 pm
Javascript does support overloading, but not the same way as C#.
function addNumbers() {
if(arguments.length==2)
return(
arguments[0] +
arguments[1]
);
if(arguments.length==3)
return(
arguments[0] +
arguments[1] +
arguments[2]
);
}
Or, more succinctly:
function addNumbers(){
var r=0;
for(var i=0;i<arguments.length;i++){
r+=arguments[i];
}
return(r);
}
January 31st, 2010 at 10:30 am
@Michael: It's not really overloading, is it? You can do some different logic depending on the number of arguments but still it all needs to be done within a single function.
February 3rd, 2010 at 2:21 am
@Waldek: Perhaps by definition it's not the same thing and programmatically it's a little different — in C# you would create multiple methods vs. javascript you would tuck the guts of those different methods into the same function.
In the end though you come out with the same result — being able to call the same-named function/method with a different number of parameters/parameter types.
February 15th, 2010 at 10:39 am
@Micheal: In this case you had prior knowledge about the already existing function. So basically, you duplicated the old function within your new one.
Now this is not possible if you do not know the previously defined function (from another SharePoint solution, another WebPart, whatever).
Example: In MOSS 2007, when one wanted to extend the context menu on list items elements, one would have to define a custom javascript function (with a hardcoded name defined somewhere in Core.js). The problem with this approach is that two solutions would not be able to extend the context menu at the same time, because of overriding (overloading would not have helped to solve this one). A better solution would probably have been to have to register the custom javascript funtions so that several ones could be active at the same time.