groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dawson <david.daw...@simplicityitself.com>
Subject Re: [RFE] Methods as expressions
Date Thu, 22 Mar 2018 10:47:25 GMT
sorry, Result is an enum that "Ok" and "Err" are members of.


On 22 March 2018 at 00:18, MG <mgbiz@arscreat.com> wrote:

> 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 break/return/continue: https://issues.apache.org/
> jira/browse/GROOVY-8301 :-)
>
> Cheers,
> mg
>
>
>
> On 22.03.2018 00:06, David Dawson wrote:
>
> 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 docs, slightly cut down, ignore the lifetime gubbins. This
> parses a number from a string, if the parse fails, it returns Err, if it
> succeeds, it does a multiply and returns the value.
>
> fn multiply(first_number_str: &str) -> Result<i32, ParseIntError> {
>     let first_number = match first_number_str.parse::<i32>() {
>         Ok(first_number)  => first_number,
>         Err(e) => *return Err(e)*,
>     };
>
>     Ok(first_number * 5)
> }
>
> If the second branch in the match expression is invoked, the method will
> return.  Otherwise, you get the Ok.
>
> I _*think*_ this feels natural, but I suspect thats more that I've just
> used it like this.
>
> That said, I have sometimes found myself reading the Groovy docs asking
> the question "how can I do an early punch out of this .each{}?"
>
>
> On 21 March 2018 at 21:47, MG <mgbiz@arscreat.com> wrote:
>
>> I am using the statically imported method
>>
>> static <T> T eval(final Closure<T> 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 Groovy natively support if-expressions or something like this, the
>> return keyword is the big question mark here for me: Should it leave the
>> expression, or the surrounding method ?
>> Maybe if a construct is used as an expression, it should follow closure
>> semantics, and return should leave the expression, whereas otherwise (e.g.
>> for potential future "inline closures" not used as expressions, for
>> instance a SQL forEach loop construct) it should leave the surrounding
>> method ?
>>
>>
>>
>> On 21.03.2018 22:08, eric.milles@thomsonreuters.com wrote:
>>
>> 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:mgbiz@arscreat.com <mgbiz@arscreat.com>]
>> *Sent:* Wednesday, March 21, 2018 4:03 PM
>> *To:* dev@groovy.apache.org
>> *Subject:* 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(...) { ... }
>>
>>   else if(...) { ... }
>>
>>   else if(...) { ... }
>>
>>   else { ... }
>>
>> }
>>
>>
>>
>> in cases where using "?" would be too complex.
>>
>>
>>
>> That uses a closure, of course, so not optimal for all applications.
>>
>>
>>
>> Question: Does a return-statement inside the if-expression leave the
>> expression, or the enclosing method in Rust ?
>>
>>
>>
>>
>>
>
>

Mime
View raw message