Re: [RFE] Methods as expressions

Hi David, thank you for the Rust example. The "Ok" and "Err" are special constructs, right - interesting, though I am not convinced... Leaving Groovy loop constructs would be possible, if their closure argument would be inlined (same as a regular for or if block), which would support

Re: [RFE] Methods as expressions

In rust, the generally promoted style is to not use returns if you can avoid it, and have the final expression in a particular block evaluated for the return. You can do returns in a flow control expression, in which case the surrounding block is returned (the function, say). >From the rust

Re: [RFE] Methods as expressions

I am using the statically imported method static T eval(final Closure cls) { cls() } right now for this. This works well, and just has the performance drawback that it is based on closures. Return here of course leaves the closure, so effectively returns from the eval method. Should

RE: [RFE] Methods as expressions

I think you could experiment with this using a closure, since return statements have this expression property already: final foo = ({ -> if(...) { ... } else if(...) { ... } else if(...) { ... } else { ... } }()) From: mg [mailto:mg...@arscreat.com] Sent: Wednesday, March 21, 2018 4:03

Re: [RFE] Methods as expressions

Having control flow statements as expressions in Groovy would feel pretty natural to me. I had always assumed there were reasons why this was not supported, so I did not bring it up...I currently use the simulated eval language extension I proposed for that, i.e. final foo = eval {  if(...) {

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

1) Very much in favor of  "parse this String with this pattern" (for all the reasons given) :-)2) Agree that "strict/unit/exact" should be replaced by more intuitive / self explanatory alternatives if possible.Cheers,mg Ursprüngliche Nachricht Von: Joe Wolf

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

(1) The parse method argument ordering was a tough call for me, but three reasons led me to favor the current ordering. The primary reason was to be consistent with the new Date/Time API itself. Most types have two static parse methods, e.g. static LocalDate parse(CharSequence value) static

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

Okay, I had a bit more of a look at the methods. I think the upto behavior is fine - though see my comment below. I have two overall comments: (1) Parse method argument order are reversed to existing methods, e.g.: Date jan01 = Date.parse('-MM-dd', '2000-01-01') LocalDate jan02 =

Re: next generation CliBuilder?

On Wed, Mar 21, 2018 at 5:23 PM, Jochen Theodorou wrote: > > > Am 21.03.2018 um 02:11 schrieb Paul King: > >> Picocli has always looked like a nice alternative. It wasn't an option >> for me before it had the api but picocli 3 seems to have that covered. >> > > can you refresh

Re: [RFE] Methods as expressions

in Rust, control flow statements are expressions. Partly this was done to enable the lifetimes to be more concisely controlled, but its a nice structure. If done in groovy, this would work (toy example, picking the right payment provider based on a property) def provider = if(request.name ==

Re: [RFE] Methods as expressions

Am 21.03.2018 um 09:27 schrieb Cédric Champeau: [...] In any case, I was doubtful as you are here before actually using it in Kotlin. After a few weeks, it became clear to me this syntax was both more concise and more self-explanatory. For me {} was always very clear, for {} starts a new

Re: [RFE] Methods as expressions

Another case is a method / function that returns a closure, would we allow the syntax: def m(String x, int y) = { x * y } ? On Wed, Mar 21, 2018 at 3:46 AM, Daniel Sun wrote: > Hi Cédric, > > If method throws exception, what does your proposed syntax look like? >

Re: [RFE] Methods as expressions

It's funny to see arguments about compatibility with Java here. Groovy's compatibility with Java is the promise that you can _almost_ copy and paste Java code and it compiles in Groovy. Not the other way around ;) In any case, I was doubtful as you are here before actually using it in Kotlin.

Re: next generation CliBuilder?

Am 21.03.2018 um 02:11 schrieb Paul King: Picocli has always looked like a nice alternative. It wasn't an option for me before it had the api but picocli 3 seems to have that covered. can you refresh my memory about the position of JCommander in this? I see some overlap. And if we go with

Re: [RFE] Methods as expressions

LOL. thanks, I probably deserved that being thrown back at me :-) I think that Jochen said it best "It seemed to be part of a bigger picture, but the bigger picture is missing." My CS background is on the weaker side, so I can't quite say what I want... Apart from Groovy, the two languages that