is the ES4 proposal as good as approved?
On Dec 19, 2007, at 9:16 PM, Peter Michaux wrote:
With so many ECMAScript engines rushing ahead to implement the ES4 proposal, it seems as though the proposal is as good as approved.
No, and I wonder if you missed my reply to your comment in John
Resig's blog:
ejohn.org/blog/state-of-ecmascript-4-dec-07/#comment-296284
John's Google Spreadsheet and generated chart is charting progress.
There will be changes to both implementations and draft specs. Don't
panic.
As I wrote in that comment, it would be a big mistake to specify
without implementations that users test and truly use for non-trivial/
synthetic inputs. It would also be a mistake to marry an early draft
just because it was implemented and used.
Perhaps there will be minor tweaks but if so many implementations contain classes, for example, such a feature will almost certainly be in ES4 final.
Let's cut to the chase: what are you worried about? Classes being in
ES4?
Has the voting majority agreed in principle to vote in favor of the
proposal?
Ecma and ISO technical groups work by consensus, not voting. As
everyone knows, consensus broke down within TG1, in a public way this
past fall -- but we are trying to repair it now.
On Dec 19, 2007 9:38 PM, Brendan Eich <brendan at mozilla.org> wrote:
On Dec 19, 2007, at 9:16 PM, Peter Michaux wrote:
With so many ECMAScript engines rushing ahead to implement the ES4 proposal, it seems as though the proposal is as good as approved.
No, and I wonder if you missed my reply to your comment in John Resig's blog:
I did see it. Thank you.
John's Google Spreadsheet and generated chart is charting progress. There will be changes to both implementations and draft specs. Don't panic.
As I wrote in that comment, it would be a big mistake to specify without implementations that users test and truly use for non-trivial/synthetic inputs. It would also be a mistake to marry an early draft just because it was implemented and used.
Perhaps there will be minor tweaks but if so many implementations contain classes, for example, such a feature will almost certainly be in ES4 final.
Let's cut to the chase: what are you worried about?
Curious about the process mostly.
Classes being in ES4?
Classes were just the easiest feature to use as an example since it is such an obvious one.
Has the voting majority agreed in principle to vote in favor of the proposal?
Ecma and ISO technical groups work by consensus, not voting. As everyone knows, consensus broke down within TG1, in a public way this past fall -- but we are trying to repair it now.
I didn't know it was consensus. I think it is much easier in a vote for someone to say no to the proposal knowing it will pass anyway than for someone to say no in a consensus group knowing his perhaps unique position will spoil the party for everyone else. It seems like it would take a very big jerk to turn down the proposal if so many companies have already invested in implementing the proposal. That is why the term "strong arm" came to mind when I commented on John's blog.
Thank you, Peter
On Dec 19, 2007, at 10:05 PM, Peter Michaux wrote:
Let's cut to the chase: what are you worried about?
Curious about the process mostly.
Here's a fresh example:
bugzilla.mozilla.org/show_bug.cgi?id=409252
My conclusion is at
bugzilla.mozilla.org/show_bug.cgi?id=409252#c5
We knew this could happen, but we planned to find out in a Firefox 3
beta. Lack of negative feedback would not be decisive, but in
combination with the incoherent state of constructor property present
value vs. memoized initial value (or value of constructor.prototype)
in ES3, would be encouraging. Negative feedback would be decisive,
and is being decisive ;-). See, no "strong-arming". You can't fool
Mother Web.
Ecma and ISO technical groups work by consensus, not voting. As
everyone knows, consensus broke down within TG1, in a public way this past
fall -- but we are trying to repair it now.I didn't know it was consensus. I think it is much easier in a vote for someone to say no to the proposal knowing it will pass anyway than for someone to say no in a consensus group knowing his perhaps unique position will spoil the party for everyone else.
This seems not to be a problem for our group ;-). I hear you, it can
be a problem on marginal issues, where people want to "avoid
conflict", but we've learned to embrace conflict.
It seems like it would take a very big jerk to turn down the proposal if so many companies have already invested in implementing the proposal. That is why the term "strong arm" came to mind when I commented on John's blog.
So many companies implementing something that needs adjusting, or
even removal, can still leave those companies carrying an extension,
if they don't adjust to match the final spec. But companies are not
working together in a standards body just to try to win by going to
market -- that is too obviously counter-productive at least for the
minority-share vendors (not necessarily for the majority-share vendor
-- see the Prisoner's Dilemma).
With so many ECMAScript engines rushing ahead to implement the ES4 proposal, it seems as though the proposal is as good as approved. Perhaps there will be minor tweaks but if so many implementations contain classes, for example, such a feature will almost certainly be in ES4 final.
Has the voting majority agreed in principle to vote in favor of the proposal?
Thanks, Peter