Another paren-free gotcha

[Allen Wirfs-Brock]

perhaps the algol/pascal/PL/I /etc use of a "then" keywords wasn't such a bud idea after all...

allen


On Sep 28, 2011, at 2:11 PM, 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.
> 
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>