Hi all,
Though Java's switch expression is still in preview phase, Groovy has
followed up its steps in my labs project:
https://github.com/danielsun1106/groovy-parser/tree/switch-expression
As you can see, switch expressions can be parsed and executed. For some edge
cases, We may polish th
By re-writing the AST as a closure expression you are going to add closure
semantics to all the variables referenced within the switch. There are a
number of differences between variables in a block and variables within a
closure.
Is there any idea of how close Java is to finalizing their synt
Have these options been tried?
```
def a = 6
def r = {->
switch (a) {
case 6:
case 8: return 'x'
case 9: return 'y'
default: return 'z'
}
}()
```
or use a local block
```
def a = 6
def r
{
switch (a) {
case 6:
case 8: r ='x'; break
You know code block is not an expression. The reason to transform switch
expression to switch statement in closure is make switch expression appear
everywhere, e.g.
```
def process(String s) { "Hello, $s" }
def a = 6
def r = process(
switch (a) {
case 6 -> 'a'
default
It helps to explain details like this that went into your design. Voting seems
premature, but "request for comment" does help share the understanding.
Typically I would expect at least a few parts of your design where options were
explored and a choice was made. By not exposing the options co
I have 2 ideas in my mind:
1) Implement switch expression from scratch, in other words, we need parse
code into a brand new`SwitchExpression` in AST, then implement flowing type
because we have static groovy, at last generate bytecode. -- need quite a
few work, but it should be able to very clos
Fix typo:
2nd transformed code in the parser to eliminate the shared variables before
instruction selection phase
->
2nd transformed code to eliminate the shared
variables before instruction selection phase
Cheers,
Daniel.Sun
-
Apache Groovy committer & PMC member
A couple notes:
1) Eclipse chose to implement switch expression as a separate AST type from
switch statement. This provides explicit separation of different parsing and
other semantics. Also in Groovy 3, method references were implemented as a new
AST type instead of converting to MethodPoint
This is just a reference implementation, we can tweak it over time.
> Now that you have a prototype in hand for conversion to ClosureExpression
> with nested SwitchStatement, would it be a good idea to at least try the
> SwitchExpression route to see how much effort difference is involved?
As Céd
Hi guys,
wondering if Groovy's macro functionality could help here ?
While I see Daniel's point about the brevity/elegance of his
implementation, I am wondering whether a low level language construct
like switch-case should be modelled by a (non-inlined) closure, due to
1) the overhead involv
PS: Sorry to criticize, Daniel. Your efforts for Groovy are much
appreciated - and Happy Birthday from me, whenever the exact date is G-)
On 04/11/2019 20:43, Daniel.Sun wrote:
This is just a reference implementation, we can tweak it over time.
Now that you have a prototype in hand for conver
It does not matter. Different people have different concerns.
Maybe we could do better if time allowed:
https://blog.joda.org/2019/11/java-switch-4-wrongs-dont-make-right.html
> and Happy Birthday from me, whenever the exact date is G-)
Thank you, MG :-)
Cheers,
Daniel.Sun
-
Apache Gro
Stephen reharsh what Cay Horstmann said two years ago :(
The main issue is that there is still a lot of switch on string/characters that
are using fallthrough for a good reason.
You can put your blinkers and pretend that those switches never exist, that
falltrough is the root of all evil and tha
Hi Rémi,
Thanks for your detailed explaining. Switch expression is useful in
some cases, but fallthrough is error prone. I seldom use switch statement,
in the past, I widely used it when I wrote lexer/parser by hand. I prefer to
use if-else instead, which is much more powerful.
Though
14 matches
Mail list logo
