groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Date Thu, 01 Mar 2018 20:27:16 GMT
+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 <glaforge@gmail.com 
> <mailto:glaforge@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
>     <jesper@selskabet.org <mailto:jesper@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>
>
>


Mime
View raw message