[code]
function AnonymousDebug()
{
//place debugger breakpoint here
}

//...pseudo code...
myObj.doSomething("foo", function(something)
{
//for debugging purposes, make call to globally scoped named function
AnonymousDebug();

//...now do something, and if I have a breakpoint set in the AnonymousDebug function I can now step through all this code
});
[/code]

Quite apart from the mess you get in a profiling tool because the function is anonymous rather than named. You need to think bigger picture – maintenance and debugging support. If you don’t know the name of the function (and you often won’t have a filename or line number either for an anonymous function) you run into a lot of trouble if you should need to use the debugger or a complementary software tool (profiler, memory leak debugger, flow tracer…)

Yes, “map” with side-effects must be named “map!” :))

VS

Steven

best,
Steven


/**
* First thing to load. The ablitiy to load dependencies in a js file
* @param file - path if relative must be relative from where the "document" is being
* loaded. This would be relative to the jsp or html file and not relative
* to the .js file. For instance if the file being loaded is:
* http://www.yourserver.com/page.html
* And in page.html you were loading js files in the HEAD with a relative SRC of
* scripts/my.js and my.js included("myOther.js") , myOther.js would be relative to page.html and NOT
* my.js.
* An easier way is to simply make the include(path) absolute from the root of the application.
*/
function include(file, id)
{
var s = document.createElement("SCRIPT");
//Make sure that the file address is absolute
var ln = document.location.pathname.lastIndexOf("/")+1;
var absPath = document.location.pathname.substr(0,ln)
if( file.substr(0,1) != "/" )
{
file = absPath+file;
}
s.src = file;
s.type='text/javascript';
s.language="javascript";
if( id != null )
s.id = id;
var head = document.getElementsByTagName('head')[0];
//Only want to add the file once even though it may be included in various places.
var scriptPath = "";
for( var i = 0; i

Anonymous function syntax (what you term “creating functions on the fly”) certainly doesn’t cause any performance issues

Yes, it might cause a performance hit. Anonymous functions are often closures, like in the second example:

Cook("lobster", "water", function(x) { alert("pot " + x); } );


When this is executed inside a function, the inline function becomes a closure. When it is executed by Cook(), symbol references inside the inline functions are looked up in 3 steps:
1) Local scope; local variables and arguments.
2) Closure scope.
3) Global scope.

#2 is the mythical performance hit. The global scope is just the outermost closure that all functions have. But closures can be chained (with the global scope always being last, and of course there could be more closure levels), which is the case here. Each extra level in the chain causes a performance hit in symbol lookup.

You might avoid the hit if the inline function only references local variables.

The performance hit has always been mentioned but not explained in Netscape docs, also related to ‘with’ statements, but I believe it is overstated. Hash lookups are extremely fast and should not cost much compared to all the other things a script interpreter does.

Anonymous function syntax (what you term “creating functions on the fly”) certainly doesn’t cause any performance issues – it’s just an alternative syntax to regular named functions.

Well, apart from the fact that if you create anonymous functions in a loop for example, you get x copies of the function object. With a named function, you get one function object with x references to it – much more efficient

And only MSIE really has issues with that, too.

Oh, and by the way Joel’s MAP function is completely un-functional as it works through side-effects, modifying the input array parameter which is a huge no-no in FP.

> Closures (a.k.a. anonymous first-class functions) are supported since C# 2.0.

Closures and anonymous first-class functions are different beasts, and while closures are often implemented via anonymous first-class functions they’re different concepts.

For example you could use anonymous first-class function in a factory-type pattern, returning different functions based on it’s input. And you don’t need closures to do that.

(cook 'lobster 'water 'PutinPut)
(cook 'chicken 'coconut 'BoomBoom)


    cook('lobster', 'water', PutInPot)
    cook('chicken', 'coconut', BoomBoom)

As for memory leaks, as long as you’re not assigning any references involving DOM elements you’ll be fine. If you are, you need to have a proper understanding of what’s going on or you could run in to problems.