You can also take a look at:
This is pattern matching implemented as a macro method, without touching the syntax of Groovy.
Macro methods FTW! :)
This kind of idea is why I love AST xforms: you can play around with a feature without forcing a syntax change into Groovy core.
This is exactly what happened with @TailRecursive. The feature proved to be good enough for 80% of the cases, for the remaining it was either verbose or required a true syntax change. It's likely this enhanced switch will encounter the same fate.
My suggestion: continue developing the feature as a standalone module, push binaries to bintray/maven central. That way you can get quicker feedback from a broader audience. When the time is right, we can revisit adding the feature into core.
Please don't get me wrong, the feature has merit but I think it requires a bit more work to further understand the ramifications of adding it to core. After all, we don't want Groovy to become a kitchen-sink language, drag down by complexity to later try to save face and claim it's a simple language and that you need to read 10 papers to understand why is that, do we? ;-)
Sent from my primitive Tricorder
> On Nov 26, 2016, at 8:26 AM, Daniel Sun <email@example.com> wrote:
> Hi Jorge,
> First of all, thanks for your proposal.
> I wonder why do you want the feature? What senarios make the code such
> as "@When('!file || !new File(path).exists()')" overwhelm existing features
> of groovy(e.g. switch statement)?
> View this message in context: http://groovy.329449.n5.nabble.com/Proposal-Pattern-matching-elixir-way-tp5737005p5737008.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.