Boolean shortcuts

Herby Vojčík herby at mailbox.sk
Wed Jan 4 10:43:42 PST 2012


Hi,

well, it is true that if {...} is ambiguous, you can always put it in 
parentheses to enforce parsing it like an expression, but it reduces the 
convenience of the proposal. If you must think whether you should put it in 
parentheses or not to prevent runtime error, you rather write { 
window:false } and reduce the insecurity.

I had in mind some more enhancements of the object literal, but they all 
would made insecure for that same reason: the code could be mistakenly 
parsed as code block. Using ({...}) I can in fact always "mark as data", but 
it is in fact very convenient that such marking is not needed, if it would 
be, it would make things less useful. If there should be "marking" needed at 
all, I think it should be there for the (free, stray) code blocks, not for 
data blocks (as seen in the parallel "No code block without introductory 
keyword" thread). What do you think of that?

If it would be unambigously (and conveniently) be able to tell code block 
apart from data block, the data blockk could be made much more powerful (and 
move even more from imperative to declarative; classes were also a move to 
that way, but it could go even further).

Like in, for example, the production: { name: aName, age: anAge, if 
(anAge>60) { retired: true, place: "rural" } else { place: "urban" } }. If 
it is ambiguous,
{ ... } with if inside would be treated as code block, but if it would be 
known that it _is_ a data block, one could put "data-if" inside without 
problems.

Herby

-----Pôvodná správa----- 
From: Mike Samuel
Sent: Wednesday, January 04, 2012 6:29 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss at mozilla.org
Subject: Re: Boolean shortcuts

2012/1/4 Herby Vojčík <herby at mailbox.sk>:
> Curse that eval-uation of a code block! This prevents not only this, but a
> lot of more possible enhancements/reforms!

I don't see the problem.  You are proposing a change to the
ObjectInitialiser production.  Francois's example just demonstrates
something we already know -- that there exist strings that will parse
as an ObjectInitialiser when you start in the Expression production
but parse as a Block when you start in the Program production.

eval('{ !window }') is and would remain a block, and eval('({ !window
})') with your proposal would be unambiguously an object initialiser,
and is a SyntaxError in ES5. 



More information about the es-discuss mailing list