On 25.07.20 20:55, Daniel Sun 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
}
```
I am partial to this. I can see it's use, but I find the multiple
returns a bit irritating. When I read code, then returns are important
points and I am trained to spot them as especially important and what
structure they are in. Of course I can see that even better here
(kinda), but I am not used to it. On the other hand it is so much alike
to what I am used to... I think I could easily oversee the conditional
sign. It happened to me when reading the examples actually
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
}
```
Initially I disliked this, but once I am getting more used to I find it
actually quite interesting. It makes the return a special kind of
function. Of course to be complete you would actually have to have
return {r -> r!=null} callSomeMethod()
Though there is a problem if I compare this with what we have.. because
this would mean:
return({r -> r!=null}).callSomeMethod()
command expressions, and that does not work out. Which then again brings
me back to
return(r -> r != null) callSomeMethod()
which should read as
return(r -> r != null).callSomeMethod()
and then it does not work out either. So what first looked like making
the language more using its own constructs is actually something
completely new, a special syntax just for return, that kinda overlaps
with command expressions and only doesn't do that because of the return
keyword... Nope, that part is a -1 to me right now
bye Jochen
