Re: About polish the generics type syntax for closure

2019-02-16 Thread Daniel.Sun
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Daniel Sun
> 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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Jesper Steen Møller
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Daniel.Sun
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,

Re: About polish the generics type syntax for closure

2019-02-13 Thread Jochen Theodorou
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Milles, Eric (TR Tech, Content & Ops)
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Daniel.Sun
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Milles, Eric (TR Tech, Content & Ops)
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Cédric Champeau
> > 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,

Re: About polish the generics type syntax for closure

2019-02-13 Thread Daniel Sun
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Cédric Champeau
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

Re: About polish the generics type syntax for closure

2019-02-13 Thread Daniel Sun
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< ->

Re: About polish the generics type syntax for closure

2019-02-12 Thread Guillaume Laforge
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

Re: About polish the generics type syntax for closure

2019-02-12 Thread Paolo Di Tommaso
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