On Mon, Apr 18, 2011 at 05:42, Jorge <jo...@jorgechamorro.com> wrote:
> I understand that it would be quite interesting to get a warning/error in
> this case:
> a= b
> (c= d)();
> ...only that there's no ASI in this case !
Jorge touches on the reason why the whole debate about ASI is a bit
misguided, in my opinion.
The "} or \n ended a statement" ASI doesn't usually bite, except in
the case of restricted productions, where it looks like it wouldn't
end.
return
{ a : 1 };
This is a situation that's extremely easy to avoid with a simple and
easily lint-able rule: "return\n<expression> is an error".
However, is it reasonable to treat strike this ASI with the same hammer?
b.on("click", function () { alert("hi!") });
I don't think so. No reasonable JavaScripter would be surprised that
the alert line ended at the }.
Furthermore, it is not the existence of ASI, but rather the lack of it
that causes problems even more frequently than the restricted
productions issue.
var a = 1;
var b = 2;
var c = { foo : "bar" }
[a, b].forEach(alert); // cannot call method 'forEach' of undefined
A "disable ASI" pragma will not catch this error. No ASI occurred!
In my years writing JavaScript, I can count on one finger the number
of times that restricted production ASI has bitten me. I immediately
abandoned the Allman style in favor of a BSD-KNF
brace-goes-with-the-start-thing style, and all was well with the
world. This no longer looked strange to me:
return {
foo : "bar"
};
I can also count on one finger the number of restricted productions
where this is an issue: throw will issue a syntax error, since the
expression is not optional, and named continue/break are very rare.
However, the "non-ASI" error above (where there is a \n followed by a
[, (, +, etc) bites a *lot*, and is almost impossible to see when
parsing the code with human eyes and brains.
The proliferation of ; is not a keyboard-tax. It is an
eyeball/brain-tax. "Why complain about semicolons? You don't even
see them." That's why. Because I want to see the relevant parts of
my code. If you put them on every line, and worse, at the
jagged-right edge of the line,
The options are to either:
* use a lint step in your development process to catch these issues
(and it's gonna have to be a pretty clever linter to know you didn't
mean to do that)
* adopt a style where such things jump out at you because they look
wrong (as I have done with npm's leading semicolon/comma style), or
* Be Very Careful about using array literals and parenthesized constructions.
I find linters to be somewhat unpleasant housepets, and thus do not
keep them in my own home, though I of course respect their place when
contributing to others' projects, and I have found that Being Very
Careful is not sustainable on teams of 1 or more humans.
Any approach that does not handle the "non-ASI error" case is not a solution.
Every time a warning prints about something that was intended, the
value of warnings is reduced. That's a bad idea. In the onclick ASI
example above, printing a warning about the ASI in that code would be
worse than useless.
If we are going to build a less wicked language, and the idea of a
warning-generating pragma seems wise, then we ought to make every
warning as relevant as possible, and not just support
backwards-compatibility, but also do our best to support the intent of
those using the language. Here's a few situations where (in my
opinion) warnings would be useful:
1. Restricted production followed by \n and an expression which is not
a method or function call, assignment, or function declaration.
// these would warn:
return
{ a: b }
/////
return
10 + 5
2. Expression followed by \n and a +, (, [, -, *, / at the same indention level.
// this would warn:
x = y
(c + d).print()
// this would not:
chain
( [some, long, thing]
, [the, next, chain, link]
, cb )
--i
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
