Wednesday, October 17th, 2007
Dealing with the Flexibility of JavaScript
Category: Articles, JavaScript
For example:
JAVASCRIPT:
-
-
connect = function(/*...*/){
-
if(arguments.length == 1){
-
var ao = arguments[0];
-
}else{
-
var ao = interpolateArgs(arguments, true);
-
}
-
if(isString(ao.srcFunc) && (ao.srcFunc.toLowerCase() == "onkey")){
-
// ...
-
}
-
if(isArray(ao.srcObj) && ao.srcObj!=""){
-
// ...
-
}
-
}
-
Commentors on the story had varied opinions.
Isabelle likes bridges:
JAVASCRIPT:
-
-
function clicked(event){ processById(event.target.id); }
-
function processById(id){ }
-
Simon Willison and Dylan Schieman discussed how jQuery and Dojo do different things depending on not only arguments, but even the contents of strings that were passed in.
Related Content:
2.1 rating from 28 votes
So this is basically about creating functions/methods that act as a decision maker based on what is passed to it? Does that make it easier though?
I could easily create a “gatekeeper” function that can handle a wide array of things and do various actions on those things, but isn’t is just another layer of abstraction?
I would assume, by the example given, that the “gatekeeper” would just call the functions that it needs to. So what is the real advantage of having gateKeeper() call func1() for me,when I should just call func1() myself?
It is cool that this is possible, but is it really necessary? Maybe this is going over my head…
EmEhRKay, no it’s about avoiding the posted example above, and it asks the same questions that you just did.
If I’m thinking along the lines of this post I think I’ve seen something similar done with JSON:
doSomething({wait:500});
doSomething({callback:”something”});
function doSomething(options)…
if (options) {
if(options["wait"] != null)
{ // run wait function }
if(options["callback"] != null)
{ // run callback function }
}
I don’t know about this. I’m more a fan of a well-defined API. I can see overloading being used to handle different data types that really do the same thing, but if I need a different number of arguments, chances are the function will be behaving differently, and should as such be named differently to better reflect the actual behaviour. I see this as just making debugging logic flow that much harder, with more branching decisions to try to figure out.
Nathan, that is exactly what the article is about, you should read it.
Wierd, totally missed the link. Must have been tired. Fair enough, I see where the author is going with it. I still prefer to avoid even using type overloading, but the way the author shows it is at least a fairly clean approach. If only JS was strictly typed so an API could actually enforce data typing. I totally agree in any case that event handlers responding to browser events should only really contain the bare minimum of code, such as a simple call to trigger a custom event or a helper function.