I know from speaking with Doug Crockford that has was less-than-impressed with ECMAScript 4 as well and was talking about going in another direction. Apparently, everything hit the fan this week with Crockford and others triumphantly moving TC39 from being splintered between ECMAScript 3.1 and ECMAScript 4 to an agreement that ECMAScript 3.1 is the way to go. Finally, some sanity in the standardization process.
I prefer the evolutionary approach versus the revolutionary approach to ECMAScript, though I’m not completely happy with the current ECMAScript 3.1 proposal. My main points of contention at this point are:
- Native JSON – I complained about this before. Language-specific features don’t belong in the core of a programming language; these should be built as extensions. If you start by supporting JSON, then you also need to provide support for XML. I’d rather this become part of the browser’s standard implementation, like
XMLHttpRequestrather than having it defined in ECMAScript.
- Method name weirdness – this applies mostly to the new
Objectmethods. They either don’t say what they do (
Object.fix()prevents new properties from being added) or don’t follow existing conventions (
propertyIsEnumerable(name, false). And then throw in Crockford’s
beget()method. I have a lot of respect for the guy, but his choice of method names is a bit too unique for general consumption.
- Objects as hashes – A lot of the new functionality around objects is intended to make them easier to use as hashes. I’d rather see a new
Hashtype that could be used for this purpose. We’re overloading
Objecttoo much as it is; I’d hate to encourage it further.
I know the proposal is still under work, so hopefully some of these issues will be addressed. I think my favorite part of the proposal thusfar is the addition of secure