The development of ECMAScript 4 is moving into an important phase: the implementors are making good on their word and are starting to implement the ECMAScript 4 proposals. Many of the features have been well thought out by this point and the implementors are working hard to integrate the necessary changes into their engines.
A couple important pieces are coming along but the most critical of which is the ECMAScript 4 Reference Implementation. They’ve released a second milestone release. You can find a copy of the implementation on the ECMAScript download page.
An important list of features is starting to become available in the reference implementation:
Implemented, may have bugs:
- classes and interfaces
- let, const, let-const
- enumerability control
- type expressions / definitions / annotations
- runtime type checks (“standard mode”)
- destructuring assignment
- slice syntax
- map & vector
- date & time improvements
- meta objects
- static generics
- string trim
- expression closures
- name objects
- type operators (is / to / cast / wrap)
Implemented and partly working, but still in flux / work to do:
- inheritance checking
- strict mode
- type parameters
- structural types
- numbers & decimal
- getters & setters (structural part is incomplete)
Now a full feature list is also being worked on by all of the implementors (as I mentioned previously). This list is going to serve as the starting point for many implementors especially when they decide which features to implement.
Adobe has also taken a step and has outlined (note the column with green/red/etc.) where they stand on all of the ECMAScript 4 proposals. They also took the time to outline their position on the proposals that they’re (currently) declining to implement.
This is a really important step in the development of the language. The implementors are staking their ground and are working hard to make sure that a solid language comes out at the end – especially one that is universally implemented. Both Google and Apple have also been participating the ECMAScript 4 mailing list, asking a lot of good questions, as they look towards creating their own ES4 implementations (in Rhino and WebKit, respectively).
Pretty much everyone can agree that a lack of dialog between implementors would surely cause problems – but that does not appear to be the case, here. Because of this openness and solid dialog ECMAScript 4 looks to have a strong future.