Why were namespaces removed from ECMAScript consideration?

Question

Namespaces were once a consideration for ECMAScript (the old ECMAScript 4) but were taken out. As Brendan Eich says in this message:

One of the use-cases for namespaces in ES4 was early binding (use namespace intrinsic), both for performance and for programmer comprehension -- no chance of runtime name binding disagreeing with any earlier binding. But early binding in any dynamic code loading scenario like the web requires a prioritization or reservation mechanism to avoid early versus late binding conflicts.

Plus, as some JS implementors have noted with concern, multiple open
namespaces impose runtime cost unless an implementation works
significantly harder.

For these reasons, namespaces and early binding (like packages before
them, this past April) must go.

But I'm not sure I understand all of that. What exactly is a prioritization or reservation mechanism and why would either of those be needed? Also, must early binding and namespaces go hand-in-hand? For some reason I can't wrap my head around the issues involved. Can anyone attempt a more fleshed out explanation?

Also, why would namespaces impose runtime costs? In my mind I can't help but see little difference in concept between a namespace and a function using closures. For instance, Yahoo and Google both have YAHOO and google objects that "act like" namespaces in that they contain all of their public and private variables, functions, and objects within a single access point. So why, then, would a namespace be so significantly different in implementation? Maybe I just have a misconception as to what a namespace is exactly.

For the sake of the bounty I'd like to know two things:

1. Does a namespace need early binding?
2. How does a namespace implementation differ from an object with private members?

Answer 1

If you declare a variable within a closure after a definition of a function will call that variable, it still uses the scoped variable.

function ShowMe() { 
    alert(myVar); //alerts "cool"
}

var myVar = "cool";

This process would get another layer of complicated with regards to namespacing.

Beyond this there are numerous namespace methods along with expand/applyIf etc that can do a lot of the same functionality. namespace() in ExtJS, or $.extend in jQuery for example. So, it may be a nice to have, but isn't an absolute need within the constructs of the language. I think that formalizing some of the extensions for Array, and support for ISO-8601 dates in Date are far more important myself. Over having to simply check each namespace layer for definition...

window.localization = $.extend(window.localization || {}, {
  ...
});

window.localization.en = $.extend(window.localization.en || {}, {
  ...
});

Answer 2

OK first Some of the terminology:

• Early binding -- check/validate when the line of code is parsed.
• Late binding -- check/validate when the line of code is executed.
• Prioritisation/reservation --I think they mean if you do early binding and check the name spaces as the code is parsed there must be a process to validate a variable name when the variable is added dynamically later on and a different set of rules for what is valid as there may be several scopes involved at this point.

I am frankly surprised that only these quite technical reasons were given. Take the common case:-

onclick=' var mymark = "donethat";'

What namespace should "mymark" belong to? There doesnt seem to be any easy answer to that question. Especially given that the code snippet:-

window.forms.myform.mybutton.onClick = ' var mymark = "donethat";'

Should put the variable in the same name space.