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