https://github.com/apache/groovy/pull/1343
On Sat, Aug 8, 2020 at 3:25 AM MG wrote:
> GitHub link ?-)
>
> On 07/08/2020 12:53, Paul King wrote:
> > I created a starting set of NV, NVI and NVD macros similar (but
> > slightly different) to what mg has described previously. I see that as
> > a sta
GitHub link ?-)
On 07/08/2020 12:53, Paul King wrote:
I created a starting set of NV, NVI and NVD macros similar (but
slightly different) to what mg has described previously. I see that as
a starting point for discussion.
> transform class to the disallowed list in CompilerConfiguration. I think
> Paul is describing a mechanism where an individual macro method is taken
> out of service.
>
>
>
> *From:* MG
> *Sent:* Tuesday, August 4, 2020 9:53 AM
> *To:* dev@groovy.apache.org;
v@groovy.apache.org; Paul King
*Subject:* Re: [PROPOSAL]Support conditional return
Hi Paul,
thanks for clearing that up :-)
@unforeseen implications: In that case a global
-Dgroovy.macro.enable=false
might also be useful, to do a quick check if it is macros that are
causing the problem (if we do not
@groovy.apache.org; Paul King
Subject: Re: [PROPOSAL]Support conditional return
Hi Paul,
thanks for clearing that up :-)
@unforeseen implications: In that case a global
-Dgroovy.macro.enable=false
might also be useful, to do a quick check if it is macros that are causing the
problem (if we do not
>
> 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 mail
gt; >vs.
> >
> > def doSomething(int a) {
> >return callB() if (a > 6 && _ > 10)
> >return callC() if (a > 5 && _ > 20)
> >return callD() if (a > 4 && _ > 30)
> > }
> >
> > -Original Mess
On 30.07.20 18:08, MG wrote:
1. Hiding a semantic "if" inside a "for"-loop syntax is not good, in my
book - in C++ I would have introduced a "returnIf"-macro to make the
intention clear in that case... ;-)
2. I was also thinking along the same line, but more like:
if(it = goo(); a>6 && it>10) {
eviously 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 &
&& 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
1. Hiding a semantic "if" inside a "for"-loop syntax is not good, in my
book - in C++ I would have introduced a "returnIf"-macro to make the
intention clear in that case... ;-)
2. I was also thinking along the same line, but more like:
if(it = goo(); a>6 && it>10) { return it }
How does the r
Hi Daniil,
1. without "??:", that only works for the case where Groovy-truth is
applicable for the return value of doChooseMethod
2. I find the [null, Character.TYPE, Integer.TYPE]-iteration idea
clearer / more DRY here irrespective of that :-)
3. Why _is_ "throw" not considered an expressi
Message-
From: Jochen Theodorou
Sent: Thursday, July 30, 2020 3:27 AM
To: dev@groovy.apache.org
Subject: Re: [PROPOSAL]Support conditional return
On 30.07.20 01:10, Daniel Sun wrote:
> Hi mg,
>
> I like your idea, but it's hard for IDE to infer the type of `it`
> during w
I agree with Johan here, I’d even go ahead and write something like:
```
def chooseMethod(String methodName, Object[] arguments) {
final methodChosen = doChooseMethod(methodName, arguments)
?: doChooseMethod(methodName, adjustArguments(arguments.clone(),
Character.TYPE))
?: doChoo
On 30.07.20 01:10, Daniel Sun wrote:
Hi mg,
I like your idea, but it's hard for IDE to infer the type of `it` during
we coding.
```
returnIf(a > 6 && it > 10) { goo() }
```
long time ago I made the suggestion of a ClosureList based on the
classic for: "(" expr (";" expr)+ ")". It got
; 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" 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
t; 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
Sent: Sunday, July 26, 2020 6:23 PM
To: dev@g
t; }
>
> 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
>
(a > 4 && _ > 30)
}
-----Original Message-
From: Daniel Sun
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=http
(The boolean case is a an aggregate, the second one only reassigns if no
value is assigned, so I would use both.
In contrast the example of yours I referred to wrote the value of foo
every line without aggregating - this is what I found non-optimal... :-) )
On 28/07/2020 12:30, Jochen Theodoro
Like - would still be nice if we had a more Groovy syntax for
Stream.of(...)/.stream() ... G-)
On 28/07/2020 12:30, Jochen Theodorou wrote:
well, with the streams API:
return Stream.of(null,Character.TYPE,Integer.TYPE).
map {doChooseMethod(methodName, adjustArguments(arguments, it)}.
find
(a > 4 && _ > 30)
}
-Original Message-
From: Daniel Sun
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
On 27.07.20 18:13, MG wrote:
[...]
Continously reassigning to methodChosen to itself once it has been set
(or in your code: Once it has acquired a value that is Groovy-true)
seems confusing & inelegant to me.
I am actually using this style quite often, because of a lack of good
alternatives. I
I also got it wrong, because I thought what you wanted to do was
overwrite methodChosen - but that is of course not what would happen in
Daniel's code ;-)
Continously reassigning to methodChosen to itself once it has been set
(or in your code: Once it has acquired a value that is Groovy-true)
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
}
```
H
> On 27. Jul 2020, at 5.16, Keegan Witt wrote:
>
> but Kotlin is the only place I've seen a trailing if like that, so maybe
> that's biasing my opinion
Not familiar with Kotlin, but Perl has " ". For example:
```
doSomething() if true
```
But that is quite different from what is proposed
On 27.07.20 12:19, MG wrote:
Hi Jochen,
I assume there is a typo ("?:" -> "?=") in your example, but apart from
that, Groovy-truth prohibits your solution for any method returning a
type which has special Groovy-truth meaning, so what we would need for
general applicability and terseness would b
Hi Jochen,
I assume there is a typo ("?:" -> "?=") in your example, but apart from
that, Groovy-truth prohibits your solution for any method returning a
type which has special Groovy-truth meaning, so what we would need for
general applicability and terseness would be:
def chooseMethod(Strin
On 27/07/2020 02:50, Mikko Värri wrote:
Earlier emails talked about supporting full closure syntax for . Is this still
included? If so, the implicit variable would naturally be the closure parameter (`it`
usually). Would it make sense to use the `it` name even in "plain expression" form,
in
On 26.07.20 20:23, Daniel Sun 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
> Second, WRT the syntax of Kotlin, it mixes the expressions and
statements. But Groovy extends the design of Java, which does not support
the mixing.
I wasn't saying we should support that because Kotlin does. I'm saying
because we *won't* support both usages, it makes it feel more out of pla
I'm leaning towards +1 for the simpler cases, but referencing earlier (labeled)
return expression values via `label._` syntax... doesn't feel like Groovy
anymore, IMHO. OTOH, just because I wouldn't use it doesn't mean it's a bad
idea.
So, if I've understood the proposal, I'd limit it to:
*
Hi Keegan,
First, maybe we could use `$` instead of `_` to represent the return value,
e.g.
```
return callA() if $ > 5
```
Second, WRT the syntax of Kotlin, it mixes the expressions and statements.
But Groovy extends the design of Java, which does not support the mixing.
Third,
Hi Sergei,
( Copied from twitter:
https://twitter.com/bsideup/status/1287477595643289601?s=20 )
> 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
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
For context, here's a summary of a discussion we had outside this thread.
Like MG, I mostly use multiple returns for early bailouts of the method,
and only occasionally otherwise where it adds additional readability. I
don't find the standard Java-like syntax for your use case
overly-cumbersome,
Reference other return value with the following syntax:
```
returnA:
return callA() if _ > 5
return callB() if _ > 10 && returnA._ > 1
```
Cheers,
Daniel Sun
On 2020/07/25 19:57:16, Daniel Sun wrote:
> Or a more verbose version:
>
> ```
> return callB() if (r -> r > 10)
> ```
>
> Cheers,
> D
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 co
Hi Mario,
> 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.
Actually even if there are only two exit points, ternary or elvis operators are
hard to meet all our require
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
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://pmd.github.io/latest/pmd_rules_java_codestyle.html#onlyonereturn).
But the reality is that sometimes (more often than not) we are forced
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 wrote:
> Hi all,
>
> We always have to check the returning value, if it match
Or a more verbose version:
```
return callB() if (r -> r > 10)
```
Cheers,
Daniel Sun
On 2020/07/25 19:51:47, Daniel Sun wrote:
> If we take intellisense of IDE into account, the proposal could be refined as
> follows:
>
> ```
> return callB() [r -> r > 10]
> ```
>
> Cheers,
> Daniel Sun
> O
If we take intellisense of IDE into account, the proposal could be refined as
follows:
```
return callB() [r -> r > 10]
```
Cheers,
Daniel Sun
On 2020/07/25 19:39:20, Daniel Sun wrote:
> Hi OC,
>
> Let me make the example a bit more complicated to clarify my proposal:
>
> ```
> def m() {
>
Hi OC,
Let me make the example a bit more complicated to clarify my proposal:
```
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')
Daniel,
-1. In my personal experience this happens very rarely, not worth a special
support in the language by far. Almost all similar cases for me are covered by
simple
def foo() {
... ...
bar()?:defaultValue
}
and the cases where this is not adequate, either due a non-null false return
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 foll
48 matches
Mail list logo
