+1 on Java compatibility, otherwise not a big fan of switch statments, I
have always found the syntax inelegant and the appliaction domain too
limited.
But it looks like with pattern matching and without the need to use
break it could finally become less of a Mauerblümchen-statement for me...
I use the similar
final result = eval {
// local variables
if(...) { return ... }
else if(...) { return ... }
...
}
static def eval(Closure cls) { cls() }
programming pattern on a regular basis*
it is one of the many reasons why adding support for inlining code to
Groovy would make a lot of sense to me. In this case where the closure
argument to the static eval-method is definitely only used once,
replacing the closure with an inlined block construct would be the
superior solution here. This poses the general question how much one
could achieve in Groovy in a generic/flexible manner, if constructs like
inlined closures would be added to the language... ?
*Note: Introducing a small helper method instead of the eval-construct
can of course be the better solution, if one does not have to pass too
many parameters to said method, and if one is not hard pressed to find a
meaningful name for it...
On 01.03.2018 17:44, Paolo Di Tommaso wrote:
I agree that groovy should continue to be compatible with java syntax
as long as possible.
Cheers,
Paolo
On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <glafo...@gmail.com
<mailto:glafo...@gmail.com>> wrote:
1) Very useful :-)
2) I think we should continue the compatibility with Java, like
we're doing for Groovy 3, and add that syntax when it's finalized.
3) It's too early to think about the implementation, let's wait
till the syntax is crystalized first!
But yeah, I like the idea of supporting it.
(and we could potentially support it before the Java version
containing it is released)
Guillaume
On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller
<jes...@selskabet.org <mailto:jes...@selskabet.org>> wrote:
Hi list
Java 11 (or perhaps 12) might see a new functionality known as
switch expressions
(https://bugs.openjdk.java.net/browse/JDK-8192963
<https://bugs.openjdk.java.net/browse/JDK-8192963>).
While the current Groovy implicit return functionality works
with the switch statement as-is, the switch/expression/ is a
more general construct, basically it is to the conditional
operator (a ? b : c) what the switch /statement/ is to
if/then/else-if/else. An example:
|int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY ->
6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case
WEDNESDAY -> 9; };|
with
|case LABEL -> expression;|
essentially sugar for
|case LABEL: break expression;|
As I see it: It could add utility to the Groovy language, and
adopting it would keep up the the Java-compatibility gap,
which I think is a valuable gateway-drug to discovering the
joys of Groovy. The "break <expression> syntax isn't pretty,
but the arrows look fine and incur no syntax compatibility
problem, as far as I can see.
Now, this being Groovy, the cases should surely support the
extended "isCase"-support, as described so well here:
http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
<http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html>
So, three questions remain:
1) Useful or not?
2) This Java compatibility - is it still a thing? I remember a
similar proposal a little while back, but this would align
better with Java.
3) This could be implemented using existing AST's if we
/_really_/ want to, but it would be clumsy. This AST
transformer compatibility - is it still a thing?
-Jesper
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
