Hi Jochen,
How about simplifying the following code?
```
Closure<():R1;(X):R2;(Y,Z):R3>
```
to
```
Closure // proposed by mg
```
Cheers,
Daniel.Sun
-
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-D
> For static Groovy, we could then skip the coercion.
Yep :-)
BTW, for dynamic Groovy, we can not get type info in the compilation time.
It's main blocker for us to implement a brand new closure based on native
lambda.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy
If we know the desired target type of a closure, and the parameters are
compatible, we could generate a Closure class which implements the applicable
Functional Interface (such as Function, Predicate or whatever). For
static Groovy, we could then skip the coercion.
-Jesper
> On 13 Feb 2019, at
Hi Jochen,
I really like your suggestion! which can solve all problems caused by
closure's versatility.
Groovy is groovy because it is Groovy, i.e. not another Java. Closure
is a killer feature in Groovy, so it's better to refine it if possible ;-)
P.S. another crazy proposal,
On 13.02.19 10:38, Daniel Sun wrote:
Hi Cédric,
I'm 100% sure a syntax like that has been discussed in the past
Well...I missed that discussion...
1. consistency between using annotations and a type-checking only feature
I propose to transform `Closure Date>` to the
annotations(i.e. `@Clos
otential cost.
From: Daniel.Sun
Sent: Wednesday, February 13, 2019 8:07 AM
To: d...@groovy.incubator.apache.org
Subject: Re: About polish the generics type syntax for closure
Thanks for your suggestion.
If the argument type is Function and the parameter type is Closure, implicit
coerce will hap
Thanks for your suggestion.
If the argument type is Function and the parameter type is Closure, implicit
coerce will happen, thus the performance will be impacted somehow. Certainly
we can use native lambda to avoid the performance issue.
In addition, Function accepts only one parameter, a bit li
Why not use "public V withSql(java.util.functional.Function fn)" in this case? @ClosureParams and @DelegatesTo are usable in Java code
as well. And they cover a whole range of cases besides 1:1 mapping. There are
a number of SAM types that can be used instead of Closure and you can also
defi
> > 2. what about polymorphic closures (aka closures which accept different
> > kind of arguments)
> You mean something like `Closure Date>`?
>
>
No, I mean things like each on a map. You can pass it a closure which
accepts a Map.Entry (1 parameter), or you can pass it a closure which
accepts key,
Hi Cédric,
> I'm 100% sure a syntax like that has been discussed in the past
Well...I missed that discussion...
> 1. consistency between using annotations and a type-checking only feature
I propose to transform `Closure Date>` to the
annotations(i.e. `@ClosureParams`), so we can keep the consist
I'm 100% sure a syntax like that has been discussed in the past, and
discarded for different reasons:
1. consistency between using annotations and a type-checking only feature
2. what about polymorphic closures (aka closures which accept different
kind of arguments)
3. the arrow syntax making it h
Hi Guillaume,
> What about the various cases, like no-arg closures?
How about `Closure< -> V>` ?
It is similar to the syntax of closure. More examples:
1)
`Closure< String, Number -> Date>`
is responding to
```
{ String x, Number y ->
return new Date()
}
```
2)
`Closure< ->
That's interesting.
What about the various cases, like no-arg closures?
On Wed, Feb 13, 2019 at 7:37 AM Paolo Di Tommaso
wrote:
> Nice!
>
> On Wed, Feb 13, 2019 at 2:50 AM Daniel Sun
> wrote:
>
>> Hi all
>>
>>I've been developing a project with Groovy 3. When I try to specify
>> the gen
Nice!
On Wed, Feb 13, 2019 at 2:50 AM Daniel Sun wrote:
> Hi all
>
>I've been developing a project with Groovy 3. When I try to specify
> the generics type for closure, I have to use annotation..., which is quite
> verbose... e.g.
> ```
> public V withSql(@ClosureParams(value= SimpleTyp
14 matches
Mail list logo