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.
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.
Waldemar
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
