/be

First, thanks for your comments, which are very helpful and welcome.

I’ve added “Parts of” to the headline and corrected “heavyweight”. I’ve also added your executive summary.

By way of explanation, I was trying to reflect what you wrote here:

… 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.

I did not intend to misrepresent you and apologise if that was the case.

Thanks again for your comments.

Tim

/be

First, “unsound for the web” does not equal “too heavyweight”. Unsound means a premise from which conclusions about namespaces were reached was false. The premise was that namespaces could be used by unrelated scripts to define names in the global scope, without making conflicts of a new kind, worse and different from the conflicts you can get today between scripts trying to set and get a single global variable foo.

The problem with namespaces and early binding is technical, in other words — not political or aesthetic — not about “weight”. As my message noted, packages already were cut by the ES4 working group this past April.

This does not mean that ES4 will never happen (it’s the next major Edition number), or that the language won’t evolve (perhaps some would prefer that, but they’re Luddites). The ES standard will evolve and Mozilla has already contributed results from its JS1.x versions to inform emerging standards such as ES3.1. That’s the good news of Harmony.

The bad news, if it is bad news, is that namespaces, packages, and early binding will have to remain ActionScript extensions to ES3 and future ECMAScript standards. The ES3 spec allows extensions, and it’s important to do so explicitly, to let implementations experiment, precisely in order for the language to evolve.

I view Harmony as a victory for those who want the language to evolve, rather than stay at ES3 or even shrink into a pet subset that everyone would use (if only they had the good taste of the subset’s advocates).

The Web is a shortest-path evolving system. It’s anywhere from silly to evil to try to stagnate JS evolution. The commitee seems agreed to this, although of course Microsoft tried to stagnate not only JS but all web standards not so long ago, and changed course only under competitive pressure.

It is definitely “fighting the last battle” (from 10 years ago) to fret about premature standardization. The web standards are way out of date and must catch up to track those evolutionary paths that are already well-trodden.

/be