On Dec 10, 2008, at 10:05 PM, David-Sarah Hopwood wrote:
Of course you should do other testing as well, to account for other
differences between non-strict and strict mode, but that's not
relevant
to semicolon insertion.
How's the weather there on planet Utopia?
Please stick to technical arguments.
This is not a technical argument, it's a political one (what's the
common good for the polis). Stop trying to distract from that with
technical digressions.
Your bold claims about a filter being zero-cost and freely available
are not credible. And you haven't produced any evidence of a non-
hypothetical problem with ASI worth solving in strict mode. Yes, there
are gotchas, but they don't seem to bite users -- meanwhile, the web
is full of JS with missing semicolon errors automatically corrected by
ASI.
Truly we could punish such sloppiness and train users who choose
strict mode, if only they'll put up with the training. That's not
credible either. Strict mode could well fail to be used if it is too
pecksniffian or gradgrindian, or whatever the right Dickensian trope
is here (both, probably).
To answer your question about how removing semicolon insertion from
strict mode would help to avoid errors, first note that a programmer
who habitually added semicolons after every statement would be less
likely to make the error above, or similar errors, such as the one
I point out in a follow-up to Neil Mix, or the one that was discussed
when we were considering '^' as a prefix for lambda expressions.
That's nice, but in practice lack of semicolons are not causing bugs.
Meanwhile, on planet Earth, there's a lot of new and old content
that's missing semicolons, which won't move to strict mode if strict
mode disables ASI.
So, if strict mode normally required semicolons (even if not in the
above specific example), and if the strict mode subset were what is
normally taught (or self-taught), then the potential for such bugs
would be reduced.
The second "if" is a big one.
What is the bug potential? Near zero, as far as I can tell. I welcome
real-world evidence to the contrary.
Here is another example that is discussed in the rationale of the
Jacaranda specification:
var a = x
+ y;
Suppose that a programmer mistypes + as ++, for example:
var a = x
++ y;
I don't welcome synthetic examples.
Again, what problem are you solving? I hate to add it, but I mean
"real-world problem", one you can show biting deployed code on the
web, or tell a few anecdotes about. Not hypothetical problems from a
spec (ES1 had a few of those too).
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
