If switch expression or pattern match macro is insufficient, could a macro be
written to cover this "conditional return"?
// "it" could easily be replaced by "_" or "$" as mentioned previously as
options
def doSomething(int a) {
returnIf(callB(), a > 6 && it > 10)
returnIf(callC(), a > 5 && it > 20)
returnIf(callD(), a > 4 && it > 30)
}
vs.
def doSomething(int a) {
return callB() if (a > 6 && _ > 10)
return callC() if (a > 5 && _ > 20)
return callD() if (a > 4 && _ > 30)
}
-----Original Message-----
From: Daniel Sun <sun...@apache.org>
Sent: Sunday, July 26, 2020 6:23 PM
To: dev@groovy.apache.org
Subject: Re: [PROPOSAL]Support conditional return
Hi Sergei,
( Copied from twitter:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbsideup%2Fstatus%2F1287477595643289601%3Fs%3D20&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C411c66fda05844d7429908d831bacc9d%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637314025668554080&sdata=vNa3dz0H%2BJAegS9Zb8HW2by0ueceqCKI6qDVFpBpbc4%3D&reserved=0
)
> But isn't it better with pattern matching? And what is "_" here?
The underscore represents the return value
> Anyways:
> ```
> return match (_) {
> case { it < 5 }: callC();
> case { it > 10 }: callB();
> case { it != null }: callA();
> default: {
> LOG.debug "returning callD"
> return callD()
> }
> }
> ```
pattern matching may cover some cases of Conditional Return, but it can not
cover all. Actually the Conditional Return is more flexible, e.g.
```
def chooseMethod(String methodName, Object[] arguments) {
return doChooseMethod(methodName, arguments) if _ != null
for (Class type : [Character.TYPE, Integer.TYPE]) {
return doChooseMethod(methodName, adjustArguments(arguments.clone(),
type)) if _ != null
}
throw new GroovyRuntimeException("$methodName not found") } ```
Even we could simplify the above code with `return?` if the condition is Groovy
truth:
```
def chooseMethod(String methodName, Object[] arguments) {
return? doChooseMethod(methodName, arguments)
for (Class type : [Character.TYPE, Integer.TYPE]) {
return? doChooseMethod(methodName, adjustArguments(arguments.clone(),
type))
}
throw new GroovyRuntimeException("$methodName not found") } ```
Cheers,
Daniel Sun
On 2020/07/26 18:23:41, Daniel Sun <sun...@apache.org> wrote:
> Hi mg,
>
> > maybe you can give some real life code where you encounter this on a
> > regular basis ?
>
> Let's think about the case about choosing method by method name and arguments:
>
> ```
> def chooseMethod(String methodName, Object[] arguments) {
> def methodChosen = doChooseMethod(methodName, arguments)
> if (null != methodChosen) return methodChosen
>
> methodChosen = doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Character.TYPE))
> if (null != methodChosen) return methodChosen
>
> methodChosen = doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Integer.TYPE))
> if (null != methodChosen) return methodChosen
>
> throw new GroovyRuntimeException("$methodName not found") } ```
>
> The above code could be simplified as:
> ```
> def chooseMethod(String methodName, Object[] arguments) {
> return? doChooseMethod(methodName, arguments)
>
> return? doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Character.TYPE))
>
> return? doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Integer.TYPE))
>
> throw new GroovyRuntimeException("$methodName not found") } ```
>
> Or a general version:
> ```
> def chooseMethod(String methodName, Object[] arguments) {
> return doChooseMethod(methodName, arguments) if _ != null
>
> return doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Character.TYPE)) if _ != null
>
> return doChooseMethod(methodName,
> adjustArguments(arguments.clone(), Integer.TYPE)) if _ != null
>
> throw new GroovyRuntimeException("$methodName not found") } ```
>
>
> Cheers,
> Daniel Sun
> On 2020/07/26 17:11:07, MG <mg...@arscreat.com> wrote:
> > Hi Daniel,
> >
> > currently I would be +/- 0 on this.
> >
> > Thoughts:
> >
> > 1. I feel I have written this before, but I myself do not encounter the
> > situation where I would need to return the result of a method call
> > only if it meets certain conditions when programming (maybe you can
> > give some real life code where you encounter this on a regular basis ?).
> > 2. If I have more than one return, it typcially is an early out, which
> > depends on the method's input parameters, not on the result of
> > another method call.
> > 3. Since I do a lot of logging / log debugging, I typically assign the
> > return value to a variable, so I can debug-log it before the one
> > return of the method.
> > 4. In fact I have had to refactor code written by other people from
> > multi-return methods to single return, to be able to track down bugs.
> >
> > So overall I am not sure one should enable people to make it easier
> > to write non-single-return methods ;-)
> >
> >
> > Purely syntax wise I would prefer
> > return?
> > for the simple case,
> >
> > and
> >
> > return <something> if <condition>
> > for the more complex one*.
> >
> > I find
> > return(<condition) <something>
> > confusing on what is actually returned.
> >
> > Cheers,
> > mg
> >
> > *Though I wonder if people would not then expect this
> > if-postfix-syntax to also work for e.g. assignments and method calls...
> >
> >
> > On 26/07/2020 16:15, Daniel Sun wrote:
> > > Hi Mario,
> > >
> > > I think you have got the point of the proposal ;-)
> > >
> > > If we prefer the verbose but clear syntax, I think we could
> > > introduce `_` to represent the return value for concise shape:
> > >
> > > ```
> > > return callB() if (_ != null && _ > 10)
> > >
> > > // The following code is like lambda expression, which is a bit
> > > more verbose return callB() if (result -> result != null && result
> > > > 10) ```
> > >
> > > Show the `_` usage in your example:
> > > ```
> > > def doSomething(int a) {
> > > return callB() if (a > 6 && _ > 10)
> > > return callC() if (a > 5 && _ > 20)
> > > return callD() if (a > 4 && _ > 30) } ```
> > >
> > > ```
> > > // optional parentheses
> > > def doSomething(int a) {
> > > return callB() if a > 6 && _ > 10
> > > return callC() if a > 5 && _ > 20
> > > return callD() if a > 4 && _ > 30 } ```
> > >
> > > ```
> > > // one more example
> > > def doSomething(int a) {
> > > return callB() if a > 6 && _ > 10
> > > return callC() + callD() if a > 5 && _ > 50 } ```
> > >
> > > BTW, the parentheses behind `if` could be optional.
> > >
> > > Cheers,
> > > Daniel Sun
> > > On 2020/07/26 11:29:39, Mario Garcia <mario.g...@gmail.com> wrote:
> > >> Hi all:
> > >>
> > >> Very interesting topic.
> > >>
> > >> The first idea sprang to mind was the PMD rule in Java saying you
> > >> should have more than one exit point in your methods (
> > >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpmd.github.io%2Flatest%2Fpmd_rules_java_codestyle.html%23onlyonereturn&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C411c66fda05844d7429908d831bacc9d%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637314025668554080&sdata=5m%2B5ejCWEicseaUp5wK0UDjHwpfMFht5ptjglZ9IWS4%3D&reserved=0).
> > >> But the reality is that sometimes (more often than not) we are
> > >> forced to break that rule. In fact sometimes we could even argue
> > >> that breaking that rule makes the code clearer (e.g
> > >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >> Fmedium.com%2Fncr-edinburgh%2Fearly-exit-c86d5f0698ba&data=02
> > >> %7C01%7Ceric.milles%40thomsonreuters.com%7C411c66fda05844d7429908
> > >> d831bacc9d%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637314025
> > >> 668554080&sdata=q8VrgoQDeH85232oyMgQT8WwljNqoUjIc4cS7GGqH5I%3
> > >> D&reserved=0)
> > >>
> > >> Although my initial reaction was to be against the proposal,
> > >> however after doing some coding, I've found that neither elvis
> > >> nor ternary operators makes it easier nor clearer. Here's why I think
> > >> so. Taking Daniel's example:
> > >>
> > >> ```
> > >> def m() {
> > >> def a = callA()
> > >> if (null != a) return a
> > >>
> > >> def b = callB()
> > >> if (b > 10) return b
> > >>
> > >> def c = callC()
> > >> if (null != c && c < 10) return c
> > >>
> > >> LOGGER.debug('the default value will be returned')
> > >>
> > >> return defaultValue
> > >> }
> > >> ```
> > >> The shortest elvis operator approach I could think of was:
> > >> ```
> > >> def m2() {
> > >> return callA()
> > >> ?: callB().with { it > 10 ? it : null }
> > >> ?: callC().with { null != it && it <10 ? it : null } }
> > >> ```
> > >>
> > >> which to be honest, is ugly to read, whereas Daniel's proposal is just:
> > >>
> > >> ```
> > >> def m() {
> > >> return? callA()
> > >> return(r -> r > 10) callB()
> > >> return(r -> null != r && r < 10) callC()
> > >> return defaultValue
> > >> }
> > >> ```
> > >>
> > >> Once said that, I would say this conditional return could be
> > >> useful only when there are more than two exit points, otherwise
> > >> ternary or elvis operators may be good enough.
> > >>
> > >> So, bottom line, I kinda agree to add conditional return, but I'm
> > >> not sure about the final syntax:
> > >>
> > >> ```
> > >> return(r -> r > 10) callB()
> > >> return callB() [r -> r > 10]
> > >> return callB() if (r -> r > 10)
> > >> ```
> > >>
> > >> Between the three I the one that I like the most is the third one:
> > >>
> > >> ```
> > >> return callB() if (r -> r > 10)
> > >> ```
> > >>
> > >> You can read it in plain english as "return this if this
> > >> condition happens".
> > >>
> > >> Apart from Daniel's use case, using this option could open the
> > >> possibility to use, not only a closure or lambda expression, but
> > >> also a plain expression. A nice side effect could be that
> > >> something like the following code:
> > >>
> > >> ```
> > >> def doSomething(int a) {
> > >> return callB() if a > 6
> > >> return callC() if a > 5
> > >> return callD() if a > 4
> > >> }
> > >> ```
> > >>
> > >> turns out to be a shorter (and in my opinion nicest) way of
> > >> switch case (when you want every branch to return something):
> > >>
> > >> ```
> > >> def doSomething(int a) {
> > >> switch (a) {
> > >> case { it > 6 }: return callB()
> > >> case { it > 5 }: return callC()
> > >> case { it > 4 }: return callD()
> > >> }
> > >> }
> > >> ```
> > >>
> > >> Well, bottom line, I'm +1 Daniel's proposal because I've seen
> > >> some cases where this conditional return could make the code clearer.
> > >>
> > >> Cheers
> > >> Mario
> > >>
> > >> El sáb., 25 jul. 2020 a las 23:55, Paolo Di Tommaso (<
> > >> paolo.ditomm...@gmail.com>) escribió:
> > >>
> > >>> It's not much easier a conditional expression (or even the elvis
> > >>> operator)?
> > >>>
> > >>> ```
> > >>> def m() {
> > >>> def r = callSomeMethod()
> > >>> return r != null ? r : theDefaultResult } ```
> > >>>
> > >>>
> > >>> On Sat, Jul 25, 2020 at 8:56 PM Daniel Sun <sun...@apache.org> wrote:
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> We always have to check the returning value, if it match
> > >>>> some condition, return it. How about simplifying it? Let's see an
> > >>>> example:
> > >>>>
> > >>>> ```
> > >>>> def m() {
> > >>>> def r = callSomeMethod()
> > >>>> if (null != r) return r
> > >>>>
> > >>>> return theDefaultResult
> > >>>> }
> > >>>> ```
> > >>>>
> > >>>> How about simplifying the above code as follows:
> > >>>> ```
> > >>>> def m() {
> > >>>> return? callSomeMethod()
> > >>>> return theDefaultResult
> > >>>> }
> > >>>> ```
> > >>>>
> > >>>> Futhermore, we could make the conditional return more general:
> > >>>> ```
> > >>>> def m() {
> > >>>> return(r -> r != null) callSomeMethod() // we could do
> > >>>> more checking, e.g. r > 10
> > >>>> return theDefaultResult
> > >>>> }
> > >>>> ```
> > >>>>
> > >>>> Any thoughts?
> > >>>>
> > >>>> Cheers,
> > >>>> Daniel Sun
> > >>>>
> >
> >
>
