After writing my library functions I can call them from any point in my code, and reuse them without any conflicts that might arise from the use of globals:

InvokeAJAXRequest(“dog”,”sound”);
InvokeAJAXRequest(“cat”,”food”);

The code funnels through the InvokeAJAXRequest function which avoids the objection of no centralized interface.

Both the “must use globals” and “no centralized place to make changes” are straw man objections. Bad code is bad code regardless of approach.

Moreover, I can accomplish the same tasks using considerably less keystrokes then the approach espoused elsewhere on this page.

function InvokeAJAXRequest(animal,responseType)
{
var url = animal + responseType + “.html ”
var xmlhttp = getHTTPRequest();

xmlhttp.open(‘GET’, url, true);
xmlhttp.onreadystatechange = function() {
if(xmlhttp.readyState == 4 && xmlhttp.status == 200)
{
DoWhateverWithTheResponse(xmlhttp.responseText);
}
else
{
window.status = “Loading…”;
}
};
xmlhttp.send(null);

}
function getHTTPRequest()
{
// native XMLHttpRequest (Firefox et al)
if (window.XMLHttpRequest)
{
req = new XMLHttpRequest();
return req;
}
//IE 6
else if (window.ActiveXObject)
{
req = new ActiveXObject(“Microsoft.XMLHTTP”);
if (req)
{
return req;
}
}
}

function DoWhateverWithTheResponse(text)
{
// Plug your returned HTML into the page
}

The sample syntax you submitted in your question isn’t quite descriptive and may prohibit to really understand the benfits. Say we rewrtie this as
new Ajax.Request(ServerName, PortName)
From there, you can then easily build new functions which receives your new object to easily communicate with the server. For instance, you could then have a script which would look like

var conn = new Ajax.Request(ServerName, PortName)
var cat = new Cat(conn)
cat.getSound()
cat.getFood()
var dog = new Doc(conn)
dog.getSound()
dog.getFood()

instead of
getCatSound(ServerName, PortName)
getDogSound(ServerName, PortName)
getCatFood(ServerName, PortName)
getDogFood(ServerName, PortName)

The second example could be a definite hassle to maintain. Also, the first example could easily manage things like connection pooling, performance stats, connection hacks, … In the second method, it would be quite difficult since there is no centralized interface.

About the disposal of objects, except for COMs, do you have any documentation showing it is necessary to dispose of JS objects? Because since “everything is object” in JS (any function declaration creates a Function object), I don’t think so or else, for every function we declare, we would have to dispose of them giving something like:

function test(){alert(“test!”)}

and don’t use a declared function because you would then create another undisposed object… I don’t think it could work like that…