Odd idea
2008/5/18 Mark S. Miller <erights at google.com>:
We've all been assuming that the current disconnect between JavaScript version numbers and Ecmascript version numbers will continue. As I was reading doku.php?id=proposals:versioning&s=versioning: /snip/ it occurred to me that it's not yet too late to end the madness. How about if we align the next JavaScript version numbers with their Ecmascript equivalents:
How about if the JavaScript version corresponding to ES4 is JavaScript 4? This also addresses the otherwise nasty issue of what the JavaScript numbering should be for ES3.1. Let's call that JavaScript 3.1 as well.
Way better than the last suggestion I heard, which was "just double it" and works pretty well for JS1.3 (not quite ES3 yet), JS1.5 (pretty much in line with ES3) and JS2 (ES4) but not for ES3.1. Also it's pretty much in line with the version jumps of XHTML5, DOM5HTML (if they persist) which are specifically there to align with the HTML5 version number.
On May 17, 2008, at 7:37 PM, Mark S. Miller wrote:
it occurred to me that it's not yet too late to end the madness. How about if we align the next JavaScript version numbers with their Ecmascript equivalents:
How about if the JavaScript version corresponding to ES4 is JavaScript 4?
There's only some small amount of madness (or irritation, really) in
either course. No one is seriously confused by JS2 being a successor
to JS1.x, but some would find the jump over missing 2.x and 3.0 odd
(see below on more problems for a JS3.1). The current plan leaves
those preferring ES to JS with the chore of doubling or halving, but
really: if you prefer ES just use it and don't bother with JS numbers.
The versioning proposal is not trying to rewrite history or over- engineer version lines, just avoid any "JS2 > ES4" doubt (which was a
certainty in the original vision, see Waldemar's docs sent to es4- discuss last month).
This also addresses the otherwise nasty issue of what the JavaScript numbering should be for ES3.1. Let's call that JavaScript 3.1 as well.
No, we want a number line that goes up sensibly. JS3.1 if it follows
1.7 would have everything on board for ES3.1 + other stuff not in ES3
that prefigures ES4.
On Sat, May 17, 2008 at 8:54 PM, Brendan Eich <brendan at mozilla.org> wrote:
No, we want a number line that goes up sensibly. JS3.1 if it follows 1.7 would have everything on board for ES3.1 + other stuff not in ES3 that prefigures ES4.
I couldn't parse that. Could you restate?
On May 17, 2008, at 9:00 PM, Mark S. Miller wrote:
On Sat, May 17, 2008 at 8:54 PM, Brendan Eich <brendan at mozilla.org>
wrote:No, we want a number line that goes up sensibly. JS3.1 if it
follows 1.7 would have everything on board for ES3.1 + other stuff not in ES3
that prefigures ES4.I couldn't parse that. Could you restate?
JS version number line:
1.0 1.1 1.2 1.3 1.4 ECMAv3 1.5 1.6
1.7 1.8
^ ^
| |
basis for ECMAv1 close to ECMAv2
Now, where does "JS3.1" go? If it's exactly the same as anything like
what's proposed for ES3.1, it does not fit on the number line above.
The line must fork somewhere between ECMAv3 and 1.6 (inclusive),
since ES3.1 as proposed does not have much (if anything) from JS1.7
or 1.8. The line must fork, because there are things in ES3.1 not in
any version on the line above.
On May 18, 2008, at 1:17 AM, Brendan Eich wrote:
On May 17, 2008, at 9:00 PM, Mark S. Miller wrote:
On Sat, May 17, 2008 at 8:54 PM, Brendan Eich <brendan at mozilla.org> wrote:
No, we want a number line that goes up sensibly. JS3.1 if it follows 1.7 would have everything on board for ES3.1 + other stuff not in ES3 that prefigures ES4.
I couldn't parse that. Could you restate?
JS version number line:
Wrapped badly by mailman. Shrinking horizontally:
1.0 1.1 1.2 1.3 1.4 ES3 1.5 1.6 1.7 1.8 ^ ^ | | basis for ES1 close to ES2
Now, where does "JS3.1" go? If it's exactly the same as anything like what's proposed for ES3.1, it does not fit on the number line above. The line must fork somewhere between ECMAv3 and 1.6 (inclusive), since ES3.1 as proposed does not have much (if anything) from JS1.7 or 1.8. The line must fork, because there are things in ES3.1 not in any version on the line above.
Not sure if lack of replies means I was unclear, but the above number
line should help highlight an awkward truth: ES3.1 is a step sideways
(and in some ways backward) for "JS" as represented by Mozilla's
implementations (Rhino is tracking SpiderMonkey). That's ok,
standardizing post-hoc can be good (making up new stuff for 3.1 is
less clearly good in this light -- more work needed to uphold the
ES3.1 < ES4 subset relation).
Since JS has evolved ahead of the standard since 1999 (and did before
then, resulting in ES1 and ES2), a "JS3.1" does not make sense. Any
ES3.1 standard would be folded into JS2 or possibly JS1.9 (the
numbers are decimals, so 1.10, 1.11, etc. are possible too, but
unlikely in my opinion).
Separately from "JS3.1", my belief is that jumping from JS2 to JS4 is
not helpful to "half" the audience (not truly half; who knows? could
be by far the majority, since "ECMAScript", .es suffix, etc. have not
caught on) who think in terms of the JS1.x evolution, however much it
might help those focused on the ES numbers.
It's hard to argue strongly for either "half" since I claim so little
is at stake in terms of confusion. If we end up seeing <script
type="application/javascript;version=4"> proliferate by accident,
I'll eat my words.
I rather suspect we will see untyped or default-typed script tags
continue to dominate, and some amount of user-agent sniffing used
server-side to deliver JS2/ES4 code to up-rev clients. I would bet
real money that the .js suffix and the unversioned "application/x-
javascript" (and even the unfortunate HTML-4.0-promulgated "text/
javascript") continue to be common for a long time, too.
Comments welcome.
On Mon, May 19, 2008 at 1:53 PM, Brendan Eich <brendan at mozilla.org> wrote:
1.0 1.1 1.2 1.3 1.4 ES3 1.5 1.6 1.7 1.8 ^ ^ | | basis for ES1 close to ES2
Not sure if lack of replies means I was unclear, but the above number line should help highlight an awkward truth: ES3.1 is a step sideways (and in some ways backward) for "JS" as represented by Mozilla's implementations (Rhino is tracking SpiderMonkey).
Only "backward" if "more complex" is "forward" ;)
That's ok, standardizing post-hoc can be good (making up new stuff for 3.1 is less clearly good in this light -- more work needed to uphold the ES3.1 < ES4 subset relation).
But ES4 is also sideways in this sense. There's a bunch of stuff in Mozilla's JS1.8 that didn't make it into ES4. Also, there's a tremendous amount of stuff in ES4 that was never in a JavaScript.
Since JS has evolved ahead of the standard since 1999 (and did before then, resulting in ES1 and ES2), a "JS3.1" does not make sense. Any ES3.1 standard would be folded into JS2 or possibly JS1.9 (the numbers are decimals, so 1.10, 1.11, etc. are possible too, but unlikely in my opinion).
Glad to hear it's decimal. (Or at least binary floating point ;).) If ES4 does become known as JS2, then, taking up the "doubling" suggestion liorean mentioned, I suggest ES3.1 also be known as JS1.55. Its successor could then be JS1.57, etc...
Separately from "JS3.1", my belief is that jumping from JS2 to JS4 is not helpful to "half" the audience (not truly half; who knows? could be by far the majority, since "ECMAScript", .es suffix, etc. have not caught on) who think in terms of the JS1.x evolution, however much it might help those focused on the ES numbers.
Surely you don't mean to suggest that ES4 represents a small evolutionary step beyond JS1.8? Wouldn't a larger increment be less misleading?
On May 19, 2008, at 4:22 PM, Mark S. Miller wrote:
Not sure if lack of replies means I was unclear, but the above
number line should help highlight an awkward truth: ES3.1 is a step sideways
(and in some ways backward) for "JS" as represented by Mozilla's
implementations (Rhino is tracking SpiderMonkey).Only "backward" if "more complex" is "forward" ;)
No, I mean "backward" in this sense: Mozilla's implementations have
had getters and setters since 1999 or so. Other minority share
browsers were forced to reverse-engineer them because Microsoft
live.com launched with user-agent testing that expected them in non-
IE browsers. This is old news, and backwards -- not progress, except
to catch IE up. Good for developers, for sure. Enough after nine
years? Hardly.
That's ok, standardizing post-hoc can be good (making up new stuff for 3.1 is less clearly good in this
light -- more work needed to uphold the ES3.1 < ES4 subset relation).But ES4 is also sideways in this sense. There's a bunch of stuff in Mozilla's JS1.8 that didn't make it into ES4.
Namely? As noted, some pieces are prototypes that will be adjusted to
match the ES4 type-based counterpart (the iteration protocol hook,
e.g.). What bunch of stuff is in 1.8 that did not make it into the
latest ES4 drafts?
Also, there's a tremendous amount of stuff in ES4 that was never in
a JavaScript.
Except under the hood, off limits to programmers, reserved for the
built-ins and the DOM.
Since JS has evolved ahead of the standard since 1999 (and did
before then, resulting in ES1 and ES2), a "JS3.1" does not make sense. Any
ES3.1 standard would be folded into JS2 or possibly JS1.9 (the numbers are
decimals, so 1.10, 1.11, etc. are possible too, but unlikely in my opinion).Glad to hear it's decimal. (Or at least binary floating point ;).) If ES4 does become known as JS2, then, taking up the "doubling" suggestion liorean mentioned, I suggest ES3.1 also be known as JS1.55. Its successor could then be JS1.57, etc...
I'm going to risk missing the joke and repeat that we wouldn't fold
any 3.1 into a distinct JS version number. This is a serious point,
since you proposed the unification of version number lines. Any ES3.1
that's a small upgrade to ES3 should not require a new JS version
number. With "no new syntax (apart from getters and setters)",
programmers should be able to object-detect new methods, not resort
to duplicative whole-script versioning. Right?
Separately from "JS3.1", my belief is that jumping from JS2 to JS4
is not helpful to "half" the audience (not truly half; who knows? could
be by far the majority, since "ECMAScript", .es suffix, etc. have not caught
on) who think in terms of the JS1.x evolution, however much it might help
those focused on the ES numbers.Surely you don't mean to suggest that ES4 represents a small evolutionary step beyond JS1.8? Wouldn't a larger increment be less misleading?
Larger than what? 0.2? The numbers are decimal tuples, so 2 - 1.8 is
arbitrarily large in the second place. We don't know until we get
there. The main point is to have a total order, not to "market" (or
counter-market, in your case :-/) by fudging the gap to be small (or
big).
On Mon, May 19, 2008 at 4:42 PM, Brendan Eich <brendan at mozilla.org> wrote:
On May 19, 2008, at 4:22 PM, Mark S. Miller wrote:
But ES4 is also sideways in this sense. There's a bunch of stuff in Mozilla's JS1.8 that didn't make it into ES4.
Namely? As noted, some pieces are prototypes that will be adjusted to match the ES4 type-based counterpart (the iteration protocol hook, e.g.). What bunch of stuff is in 1.8 that did not make it into the latest ES4 drafts?
Ok, I looked, and it's a lot less than I expected. "watch" is an example. (Unless I didn't notice its inclusion).
So, yes, you're right. ES4 is a successor to JS1.8.
Also, there's a tremendous amount of stuff in ES4 that was never in a JavaScript.
Except under the hood, off limits to programmers, reserved for the built-ins and the DOM.
Huh? Classes, Type declarations, Namespaces!, perhaps Packages and/or Units, if these are still on the table.
Namespaces is a huge addition to the complexity of the language, and the one I'm least happy about.
Glad to hear it's decimal. (Or at least binary floating point ;).) If ES4 does become known as JS2, then, taking up the "doubling" suggestion liorean mentioned, I suggest ES3.1 also be known as JS1.55. Its successor could then be JS1.57, etc...
I'm going to risk missing the joke
To avoid running into ES4, successors to ES3.1 will be ES3.14, ES3.141, ..., approaching ESpi. (Thanks Donald Knuth for the idea)
and repeat that we wouldn't fold any 3.1 into a distinct JS version number.
Ok then, I'm happy to stop arguing about this. I just thought that this odd idea might be seen as helpful. If not, forget it. We have enough substantive issues to argue about ;).
On May 19, 2008, at 5:41 PM, Mark S. Miller wrote:
On Mon, May 19, 2008 at 4:42 PM, Brendan Eich <brendan at mozilla.org>
wrote:On May 19, 2008, at 4:22 PM, Mark S. Miller wrote:
But ES4 is also sideways in this sense. There's a bunch of stuff in Mozilla's JS1.8 that didn't make it into ES4.
Namely? As noted, some pieces are prototypes that will be adjusted
to match the ES4 type-based counterpart (the iteration protocol hook,
e.g.). What bunch of stuff is in 1.8 that did not make it into the latest ES4
drafts?Ok, I looked, and it's a lot less than I expected. "watch" is an example. (Unless I didn't notice its inclusion).
Object.prototype.watch and unwatch have been in SpiderMonkey for ~12
years (memory fades -- in rev 1.1 on cvs.mozilla.org, I recall
implementing in Netscape's private CVS years before mozilla.org was
founded).
Also, there's a tremendous amount of stuff in ES4 that was never
in a JavaScript.Except under the hood, off limits to programmers, reserved for the
built-ins and the DOM.Huh? Classes, Type declarations, Namespaces!,
Classes under the hood (interfaces too) in built-ins and the DOM and
browser object models. You cannot bootstrap JS in JS without
something like classes.
Type declarations mean several things, but let's pick just structural
types: under the hood in SpiderMonkey at least.
Namespaces: fair enough, although the built-ins still get special
treatment. What else are the [[Get]], etc. "internal property names"
in ES1-3, but non-default namespace prefixes disguised as semantic
brackets. These names are mangled in a way that cannot be spelled in
the language, yet they are property names.
perhaps Packages and/or Units, if these are still on the table.
They were cut -- please try to keep up, we ES4-ers are spending time
keeping up with 3.1 :-/.
Namespaces is a huge addition to the complexity of the language, and the one I'm least happy about.
Actually, I agree with you that namespaces add more complexity than
classes alone (if that's what you mean). We've been working on them
for a long time (Waldemar can tell you about the first go-round).
They're too useful to lose in favor of privileged built-in names and
UGLY conventions for the lusers.
and repeat that we wouldn't fold any 3.1 into a distinct JS
version number.Ok then, I'm happy to stop arguing about this. I just thought that this odd idea might be seen as helpful. If not, forget it. We have enough substantive issues to argue about ;).
Will do, although a transcendental version number will come in handy
some day, I'm sure ;-).
We've all been assuming that the current disconnect between JavaScript version numbers and Ecmascript version numbers will continue. As I was reading doku.php?id=proposals:versioning&s=versioning:
For the application/javascript type, the version
values already in use are 1.0, 1.1, 1.2, 1.3, 1.4,
1.5, 1.6, and 1.7 (note that these are not specified
by RFC 4329 or by any ECMA specification).
Implementations of ES4 MUST process content
of type application/javascript with version equal
to 2 the same as they would
application/ecmascript with version equal to 4.
it occurred to me that it's not yet too late to end the madness. How about if we align the next JavaScript version numbers with their Ecmascript equivalents:
How about if the JavaScript version corresponding to ES4 is JavaScript 4? This also addresses the otherwise nasty issue of what the JavaScript numbering should be for ES3.1. Let's call that JavaScript 3.1 as well.
We've all been assuming that the current disconnect between JavaScript version numbers and Ecmascript version numbers will continue. As I was reading <http://wiki.ecmascript.org/doku.php?id=proposals:versioning&s=versioning>: # For the application/javascript type, the version # values already in use are 1.0, 1.1, 1.2, 1.3, 1.4, # 1.5, 1.6, and 1.7 (note that these are not specified # by RFC 4329 or by any ECMA specification). # Implementations of ES4 MUST process content # of type application/javascript with version equal # to 2 the same as they would # application/ecmascript with version equal to 4. it occurred to me that it's not yet too late to end the madness. How about if we align the next JavaScript version numbers with their Ecmascript equivalents: How about if the JavaScript version corresponding to ES4 is JavaScript 4? This also addresses the otherwise nasty issue of what the JavaScript numbering should be for ES3.1. Let's call that JavaScript 3.1 as well. -- Cheers, --MarkM