🚀 go-pugleaf

One simple example where prototyping could be very bad:

function1();
function function1(){
    Array.prototype.getItemIndex = function (item){
        for(var i=0;i<this.length;i++){
            if(item==this[i]){return i}
            }
        return undefined;
        }
    var array = [1,3,5,2,4,6];
    DoSomething();
    if(array.getItemIndex(10)==undefined){
        alert("undefined");//do something
        }
    else{alert("defined")}//do something else
    }
function DoSomething(){
    Array.prototype.getItemIndex = function (item){
        for(var i=0;i<this.length;i++){
            if(item==this[i]){return i}
            }
        return -1;
        }
    //do some stuff...
    }

Now, the creator of function1 would expect his script to work properly 
-- and it will as long as he doesn't include DoSomething() in his 
script. Once he includes DoSomething() in his script, the public Array 
object has been changed to conflict with his script. The public objects 
are outside of the scope of namespaces. Both of these prototype methods 
are perfectly legitimate, but will conflict with each other, and you'll 
have a **very hard time** tracking down the problem!!!

This kind of thing can very easily happen with nested scripts especially 
when event handlers are invloved. The DoSomething() function might not 
even be in your script, and you might not know of its existence... Of 
course using private scripting engines avoids these issues when used 
carefully, but I'd rather keep everything in its own namespace and safe 
from any chance of conflicts...

-- 
Harbs
http://www.in-tools.com