Is there a published specification that all these implementors will be using?
Thanks, Geoff On Feb 20, 2008, at 3:38 PM, Brendan Eich wrote: > 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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
