Boolean shortcuts

Herby Vojčík herby at mailbox.sk
Wed Jan 4 15:46:49 PST 2012


Hi,

thanks for the link. I will look at it. I am just working on something 
similar, just because it appeared inside my mind and it is really nice (if 
it was possible). So I probably will finish it and put it online, even if it 
will be put away (though I'd like not to).

I'm curious about in what scenarios {} as object literal brings is a 
breaking change.

I devised a "freestanding {...} is always an object literal" rule with "if 
you want free code block, introduce it in appropriate context" (like a 
do-expression, for example, even dumb do while (0) is good as a workaround) 
counsel. I see it breaks old code, but I am looking at it as a feature for 
the new version, so breaking old code is not a problem and I do not see 
(yet) any problems when used in context of ES.next only. Is there something 
beyond free code blocks?

Herby

-----Pôvodná správa----- 
From: Brendan Eich
Sent: Wednesday, January 04, 2012 11:56 PM
To: Herby Vojčík
Cc: François REMY ; mikesamuel at gmail.com ; es-discuss
Subject: Re: Boolean shortcuts

On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:

> Hi,
>
> as I already posted in the parallel thread, there is that strawman called 
> "do expression" by dherman that does just that.
>
> I feel like crying when I see how powerful data constructs could be if not 
> hampered by "possible to parse as code block" ambiguity.

Yes, I have felt like crying too -- I did some work (see 
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html) on 
unifying blocks and object literals, inspired by others on this list, but it 
didn't pan out. It's increasingly future-hostile as we try to extend object 
literals.

Trying to invert precedence so "{}" as a program source makes an empty 
object instead of an empty block, IOW favoring expressions over statements, 
is a breaking change. Not only for eval, but for other variants such as 
javascript: URLs.

So, I've put unifying blocks and object literals on the back burner. A more 
nuanced approach that doesn't break compatibility so much would be welcome, 
but I don't see it.

/be



More information about the es-discuss mailing list