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