(Almost) everything is expression

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Fri Nov 11 01:42:17 PST 2011


On 11.11.2011 13:26, François REMY wrote:
> <aside note>
>
>    let x = q ? 10 : 20;
>
>    Why we're reinventing the wheel here is up to me.
>
> </aside>
>

I noted it in the initial letter. Yes, we have the sugar for this 
particular case for years (the ternary operator). But also with this I 
mention that it doesn't allow _conveniently_ handle complex bodies of 
consequent and alternative nodes of an if-expression. Please re-read my 
initial letter.

Once again, the idea is to have _in addition_ for all the statement 
parts the same expression parts (not only for if-statement, so sorry, I 
don't buy your "reinventing the wheel").

And since this is exactly the _addition_, but _not the replacement_, 
it's still possible to use statement forms (w/o explicit semicolon). But 
if you need an expression form, use it. The same as with FD and FE.

Dmitry.

> -----Message d'origine----- From: Dmitry Soshnikov
> Sent: Friday, November 11, 2011 8:54 AM
> To: David Herman
> Cc: es-discuss Steen
> Subject: Re: (Almost) everything is expression
>
> On 11.11.2011 11:43, David Herman wrote:
>>> Brendan and Dave mention explicit semicolon. Yes, it's seems so by 
>>> the grammar (though, have to check more precisely), but it can be 
>>> acceptable price.
>> It's a serious price, though. Today if I write:
>>
>>      if (q) { ... }
>>      else { ... }
>>      (f())
>>
>> then ASI kicks in after the else body. If we make if-statements into 
>> expressions, then either the above becomes a single expression, which 
>> is a serious and subtle backwards-incompatible change, or we define 
>> lookahead restrictions on ExpressionStatement, and introduce a 
>> refactoring hazard:
>>
>>      x = if (q) { ... }
>>          else { ... }
>>      (f())                 // oops, this is now a parameter list on 
>> the RHS of the assignment!
>>
>> I'm not positive, but that seems like a serious issue to me.
>
> Yes, all this relatively true, but personally I don't see the big issue.
> In practice we already have such a case e.g. for FD (function
> declaration) vs. FE (function expression).
>
> The former doesn't require semicolon, the later does. Though, in the
> later case (FE), today most of programmers put explicit semicolon to
> avoid problems with scripts minimizing. From this viewpoint it's not a
> big price, since even now the programmers are already used to such cases.
>
> Regarding old code it's also not the issue since there is no such old
> code, it's a syntax error. And even if a user will refactor code (to
> make it look shorter and elegantly), she should be aware about this case
> (again -- just like with FD and FE -- users are aware about it):
>
> Was:
>
> var x;
>
> if (q) {
>   x = 10;
> } else {
>   x = 20;
> }
>
> Becomes:
>
> let x = if (q) {
>   10;
> } else {
>   20;
> };
>
>>> Nope, have to think more on this...
>> You might want to take a look at this:
>>
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
>>
>
> Yep, I've seen it before briefly; will check it more precisely later,
> thanks.
>
> Dmitry.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list