On Apr 18, 2011, at 12:14 PM, Isaac Schlueter wrote:
> [snip, and huzzah! ;-)]
> 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!
Ding ding ding...
> 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"
> };
Right, and crock has made this point too. Style rule with substance (like it or
not) backing it, better than mere (and endless) aesthetic arguments.
> 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.
Yes, this is a good point too, I forgot to raise it. It is why people are told
to start separate JS files which may end up in a concatenation with a lone ;.
Thanks for raising it.
> 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,
I agree, but in a friendly spirit suggest typing ; is a tax too, however much
lesser.
> 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.
Agree emphatically. We have had similar experiences!
> 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.
Agreed. See my 'with' strict warning story.
> 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
Some expressions that do not involve calling, assigning, or otherwise
potentially having effects (declaring, where the declaration is a misplaced
function expression) still may have effects (e.g. getters).
Your suggestion seems to be to avoid analysis and warn based only the syntax of
the expression that follows on a separate line a bare, unterminated return. I
think I agree, but I wanted to call this choice out for more discussion.
>
> 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 )
Indentation, yay. Necessary in your view, or could you just ignore everything
except the separation by a line terminator?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
