As Jeff has laid out, with helpful comments from Michael O'Brien, Lars, and Graydon, we are entering a phase of ES4 work where practical implementations will adopt and implement proposed parts of the new language. We need to do this to shake out proposals and gain critical feedback from implementors. We hope to get usability results from programmers too.
I agree with Michael's point about the RI being both alpha and omega among implementations, so RI work will continue. But practical implementations, besides enabling usability testing with real programmers, will help weed out potential problems to do with performance and security that the RI blissfully ignores. As Graydon and Michael point out, the waterfall diagram (even if you put the RI earlier in the waterfall) does not reflect the wheels within wheels (waterwheels?) that must cycle at several levels of design, implementation, and even usability testing, in order to reach the ES4 spec we aspire to write. So take that waterfall diagram more as a management crutch ;-). Finally, we absolutely aspire to build our existing testsuites up to cover as much of the new language as we can. Test-driven development is the only way to go (I speak from painful experience back in the Netscape days :-/). The good news is that I believe we will have many ES4 implementations coming up in the next few months, working in parallel to improve the spec and RI. I know of at least these already under way: * ES4 RI (SML + ES4 self-hosted) * MbedThis (C + Java) * Rhino (Java) * SpiderMonkey (C) * Tamarin+ESC (C++ + ES4 self-hosted) If you are implementing any part of ES4 and want to join forces, please reply. We aim to track progress using the infrastructure created by John Resig: http://ejohn.org/blog/state-of-ecmascript-4-dec-07/ http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2 I believe that the shared spreadsheet URL given above is correct, but John can provide the latest information as well as grant write access. My hope is that implementors can edit the spreadsheet to record progress, providing verifiable builds and even open source for their implementations, as they go. Again I'll defer to John on this. We propose to communicate among implementation teams using es4- [EMAIL PROTECTED], since (a) the list is not terribly high-traffic, (b) we aim to operate transparently, and (c) we believe most of you are interested at least as onlookers, if not as implementors. We can split lists if we run into a problem, but I don't foresee one. To provide focused face-to-face time working together and building rapport among the principals, we are thinking of meeting roughly every month, with this strawman schedule: March 17-21 - Mountain View, CA April 14-18 - Newton, MA May 12-16 - Vancouver, BC This is very straw, so please don't flame it or it will ignite! But please do feel free to suggest alternative dates and locations. We hope to host anyone who has known reputation on this list and who wants to help, or who is already implementing. Jon Zeppieri has already helped with the RI, for example, and he's welcome to attend. More details on the meetings as we firm things up. Anxiety about commercial pre-release implementations gaining undue influence over the proposed standard naturally arises, and I wanted to address this briefly: Speaking for Mozilla, we do not intend to throw trump cards during this new phase of proposed-ES4 development based on implementations. We've implemented extensions in the past, some of which are popular, others not so popular. We carry what we create until we can drop it, ideally in favor of a standardized form that's an actual improvement. This has gone on since Netscape days. We try not to mess around with marginal extensions, so the few mistakes we're still carrying, e.g. the magic __proto__ Object.prototype property, in both its read and write modes, reflect usability gaps in the language. For example, __proto__ is useful in the absence of ES4's Map to make an object be a "hash": var obj = {__proto__:null, "key1":val1, ... "keyN":valN}; and that use-case should be better served by something like ES4's Map proposal. But as noted in the thread that started here, __proto__ is not proposed in any way for inclusion in ES4. I bet the other implementators cited above would make a similar "no trump cards" pledge. The point of this proposed-ES4 implementation exercise is not to develop and deploy production code to the Web, rather to gain crucial feedback from implementors and programmers -- a kind of "open source" or "permanent beta" approach to standardization, where interoperation among ES4 implementations can be demonstrated with tests and real code before the standard is finalized. Any questions? Feel free to reply-all. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
