First of all, great work, Daniel ! I'm confident that making the "lambdas"
be "closures" in Groovy is enough. I stated it in the past but I'm going to
repeat myself here, I don't think having 2 syntax for "closures/lambdas"
with slightly different semantics would help our users/language. That said,
On 19.10.2016 09:09, Cédric Champeau wrote:
First of all, great work, Daniel ! I'm confident that making the
"lambdas" be "closures" in Groovy is enough.
I think it won't be enough for :: and MethodClosures. Actually, Daniel,
are those supported in the new Grammar and what are they mapped to
Hi Jochen,
I plan to map Java's *::* to Groovy's *.&*, the following code is ok
now. What do you think about it?
[1, 2, 3].stream().forEach(System.out.&println) // object method,
[1, 2, 3].stream().forEach(System.out::println)
[1, 2, 3].stream().forEach(Objects.&requireNonNull) //
That's what I thought too.
Although there's one :: case that .& doesn't support in Groovy.
(details escape me at this point as I'm in a hurry to go & grab lunch :D)
On Wed, Oct 19, 2016 at 12:23 PM, daniel_sun
wrote:
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the followin
2016-10-19 10:51 GMT+02:00 Jochen Theodorou :
>
>
> On 19.10.2016 09:09, Cédric Champeau wrote:
>
>> First of all, great work, Daniel ! I'm confident that making the
>> "lambdas" be "closures" in Groovy is enough.
>>
>
> I think it won't be enough for :: and MethodClosures. Actually, Daniel,
> are
Hi Daniel
Be careful with that approach, as it won’t work for static methods — leading to
very different semantics for the two languages.
Also, you won’t be able to support constructor references without some new AST
construct, I guess.
-Jesper
> On 19. okt. 2016, at 12.23, daniel_sun wrote:
On Wed, Oct 19, 2016 at 8:25 PM, Guillaume Laforge wrote:
> That's what I thought too.
> Although there's one :: case that .& doesn't support in Groovy.
> (details escape me at this point as I'm in a hurry to go & grab lunch :D)
I think these are the references you had in mind Guillaume:
https:/
> De: "Jesper Steen Møller"
> À: dev@groovy.apache.org
> Cc: "Remi Forax"
> Envoyé: Mercredi 19 Octobre 2016 01:15:47
> Objet: Re: Lambda expression for Groovy 3
> "Real lambdas" with the full invokedynamic treatment is a big job, and
> requires
> static type inference.
> Given that Groovy can
Hi Jesper,
> Be careful with that approach, as it won’t work for static methods —
> leading to very different semantics for the two languages.
'.&' can reference the static methods, here is the sample code:
[1, 2, 3].each(Objects.&requireNonNull)
> Also, you won’t
Hi Cedric,
> De: "Cédric Champeau"
> À: dev@groovy.apache.org
> Envoyé: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3
> First of all, great work, Daniel ! I'm confident that making the "lambdas" be
> "closures" in Groovy is enough. I stated it in the past but I'm
Daniel,
you have also to test that Type::method work not only with static methods but
also with instance method.
The awful case being when you have a static method that takes an instance in
parameter that 'overload' an instance method, like Integer.toString() and
Integer.toString(int).
Rémi
-
Hi Rémi,
Groovy can choose the right method to call :)
assert ['1', '2', '3'] == [1, 2, 3].collect(Integer.&toString)
Cheers,
Daniel.Sun
发件人: Remi Forax [via Groovy]
发送时间: 2016年10月19日 19:29
收件人: daniel_sun
主题: Re: Lambda expression for Groovy 3
Daniel,
On 19.10.2016 12:23, daniel_sun wrote:
Hi Jochen,
I plan to map Java's *::* to Groovy's *.&*, the following code is ok
now. What do you think about it?
[1, 2, 3].stream().forEach(System.out.&println) // object method,
[1, 2, 3].stream().forEach(System.out::println)
[1, 2, 3].st
On 19.10.2016 12:26, Cédric Champeau wrote:
2016-10-19 10:51 GMT+02:00 Jochen Theodorou mailto:blackd...@gmx.org>>:
On 19.10.2016 09:09, Cédric Champeau wrote:
First of all, great work, Daniel ! I'm confident that making the
"lambdas" be "closures" in Groovy is enough.
On 19.10.2016 12:34, Jesper Steen Møller wrote:
Hi Daniel
Be careful with that approach, as it won’t work for static methods — leading to
very different semantics for the two languages.
Also, you won’t be able to support constructor references without some new AST
construct, I guess.
Norma
On 19.10.2016 14:12, daniel_sun wrote:
Hi Rémi,
Groovy can choose the right method to call :)
assert ['1', '2', '3'] == [1, 2, 3].collect(Integer.&toString)
I am sure that works only because the static Integer.toString(int) and
the virtual Integer.toString() return the same values. If
Hi,
I´dd like to collect here a list of things we have to do to get the next
2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see
the following we should integrate the new parser (could be done for
2.4.x
If we could get a fix for https://issues.apache.org/jira/browse/GROOVY-7966,
it would help Gradle, because it prevents our caching from working without
a hack (basically sorting files, which has a performance cost).
2016-10-19 16:32 GMT+02:00 Jochen Theodorou :
> Hi,
>
> I´dd like to collect here
+1 for releasing 2.4.8 as soon as possible. There are already 67 fixed
issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20GROOVY%20AND%20fixVersion%20%3D%202.4.8%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC
Am 19.10.2016 um 16:32 schrieb Jochen Theodorou:
Hi,
I´dd like to
Hi Jochen,
Thanks for your detail explanation. I'll try to implement the method
reference for Groovy 3 :)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736212.html
Sent from the Groovy Dev mailing list ar
+1 for releasing 2.4.8 asap
Does anyone have any idea of how long is going to take the new parser to be
ready ? It's a matter of weeks, months, maybe days? I think that
information would help to plan future releases.
Mario
On 19 Oct 2016 17:15, "Pascal Schumacher" wrote:
> +1 for releasing 2.4
Mario, did you try the WIP by Daniel Sun, to provide feedback, see how it
works on your code base?
That's also a way to help and assess how far we are from having the new
parser ready, if you've got a bit of time to try it out.
On Wed, Oct 19, 2016 at 6:11 PM, Mario Garcia wrote:
> +1 for releas
On 19.10.2016 18:11, Mario Garcia wrote:
Does anyone have any idea of how long is going to take the new parser to
be ready ? It's a matter of weeks, months, maybe days? I think that
information would help to plan future releases.
I just made an experiment in which I moved the antlr2 parser in i
Hi Rémi,
'this' inside the closure references the instance of enclosing class, so
no difference exists in the semantic of 'this'.
PS: I verified it using groovy2.4.7
Cheers,
Daniel.Sun
在 "Remi Forax [via Groovy]"
，2016年10月19日 下午7:17写道：
Hi Cedric,
De:
On 19.10.2016 12:21, Remi Forax wrote:
[...]
The main issue i see of having one semantics is that the meaning of
'this' in a Groovy closure means the closure itself while 'this' in a
Java lambda means the enclosing object, so { -> this } in Groovy is a
substitute to () -> this in Java.
that is
25 matches
Mail list logo
