groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: [RFE] Methods as expressions
Date Thu, 22 Mar 2018 00:18:05 GMT
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 
> <mailto: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
>     <mailto: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]
>>     *Sent:* Wednesday, March 21, 2018 4:03 PM
>>     *To:* dev@groovy.apache.org <mailto: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