FYI the switch statement is likely to become an expression in Java.next (18.3 or 18.9) thus Groovy will have to support it at some point.
------------------------------------------- Java Champion; Groovy Enthusiast http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Thu, Oct 5, 2017 at 8:47 PM, Graeme Rocher <[email protected]> wrote: > I agree. I'm not keen on if/switch on the right hand side of > assignments at all and a??.b.c is very obscure > > On Thu, Oct 5, 2017 at 8:01 PM, <[email protected]> wrote: > > Before Groovy 2.6 and 3.0 are released, will there be a review of the > syntax > > additions for inclusion in the final release? I get "!in" and > > "!instanceof". However, I'm am getting the feeling of "Kitchen Sink" or > > "just because we can" on recent additions to the parser. I'm not seeing > any > > of the new syntax adding something I can't get already with reasonably > > succinct code: > > > > > > > > `foo?['bar']` is just `foo?.getAt('bar')` > > > > > > > > `a === b` is just `a.is(b)` > > > > > > > > `a ?= b` is just `if (!a) a = b` > > > > > > > > `a??.b.c.` is just `a?.b?.c` > > > > > > > > 'def a = if (x) b else c` is just `def a = x ? b : c` > > > > > > > > `def a = switch (x) { case 'b': b; break; case 'c': c; break; }` (or > > whatever has been proposed) is just `def a = { switch(x) { ... } )()` > > > > > > > > These last two really bother me because statements and expressions have a > > distinct meaning in the language and now the meaning is blurred quite > > completely. Why is all of this new syntax necessary? Isn't it enough to > > have support for Java array init and lambdas now? > > > > > > > > > > > > All these new syntax options are making it difficult to entice fellow > Java > > programmers around the office into using Groovy because it is Java plus a > > *few* very convenient additons. I almost want to be able to turn off > some > > of these additions so the compiler errors on them. > > > > > > > > Eric Milles > > Lead Software Engineer > > > > Thomson Reuters > > > > Email: [email protected] > > > > Phone: 651-848-7040 > > > > > > > > -- > Graeme Rocher >
