Another paren-free gotcha

[Quildreen Motta]

**
On 28/09/11 18:11, Waldemar Horwat wrote:

Thinking about the implications of paren-free, I see additional potential
trouble spots in addition to the one I mentioned in the meeting yesterday:

Start with ES5 code:

if (a + b)
  (x.y)()
z++

Now (erroneously) convert it to paren-free:

if a + b
  (x.y)()
z++

This doesn't give a syntax error; it silently changes the meaning of the
program.


I'm not sure how this is much different from the rules you have now with
ASI, though if this were such a problem, a block statement could be required
with paren-free conditions that aren't followed by a block sub-statement, or
a keyword prefixed one. Though, again, I don't think it would make much
sense — as the current syntax is pretty consistent with what's expected from
ASI rules.

Oh, yes, people often blame ASI because it's unintuitive and blah blah blah.
I think it's more a problem of people expecting JS to be parsed as any other
C-language family (more close to Java, perhaps?), whereas semicolons are
treated in a manner almost close to Python, except for the fact you have
tokens for implicit statement continuations instead of a single escape
character for explicit statement continuation.


Another hidden pitfall of the paren-free experience is illustrated by the
expression refactoring to add parentheses:

Start with ES5 code:

if (a + b/g > f) f = a + b/g

Convert it to paren-free:

if a + b/g > f {f = a + b/g}

So far so good; it works.  However, later someone discovers that the code
had a logic error, the fix to which is to divide the sum a+b by c instead of
dividing only b by c.  So he fixes the code to:

if (a + b)/g > f {f = (a + b)/g}

Oops.  Now the / starts a regexp.  There is an extra closing brace which
will simply close the enclosing scope early, so a syntax error likely won't
appear for a while.

 This is more of a real problem, with which I am concerned with =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/b2ed611c/attachment-0001.html>