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
___
De: "Cédric Champeau" <[hidden email]>
À: [hidden email]
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&quo
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
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
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 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: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
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: Lamb
nt).
Rémi
- Mail original -
> De: "daniel_sun"
> À: d...@groovy.incubator.apache.org
> Envoyé: Mercredi 19 Octobre 2016 12:23:09
> Objet: Re: Lambda expression for Groovy 3
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the
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&q
GenericsType[]::new
Thanks for your reminding :)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736201.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
> 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
> requir
object method,
>> [1, 2, 3].stream().forEach(System.out::println)
>> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1,
>> 2,
>> 3].stream().forEach(Objects::requireNonNull)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>
rintln)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Lambda-expression-f
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
p;requireNonNull) // class method, [1,
> 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy D
ts.&requireNonNull) // class method, [1, 2,
3].stream().forEach(Objects::requireNonNull)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
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
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,
n below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736191.html
To unsubscribe from Lambda expression for Groovy 3, click
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpb
On 19.10.2016 02:49, daniel_sun wrote:
The new parser is based on Java8, so it has to target to Groovy3. As far
I know, there are some amazing features under development or test, e.g.
MOP2, new Joint compiler, Macro(appears at the snapshot of 2.5.0), etc.
Looking forward to them :)
(a) I think
re if that is more easy to accomplish.
bye Jochen
------------
If you reply to this email, your message will be added to the
discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy
allows parentheses-less parameter for lambda when the
>>>>> parameter is
>>>>> > single and without type: e -> e, but *Groovy* only allows
>>>>> parameter with
>>>>> > parentheses: (e) -> e.
>>>>
nd not so ok. Here again it would be no problem if it is
recognized as Closure if that is more easy to accomplish.
bye Jochen
If you reply to this email, your message will be added to the
discussion below
___
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736182.html
To unsubscribe from Lambda expression for Groovy 3, click
here<http://groovy.3
-
If you reply to this email, your message will be added to the
discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736171.html
To unsubscribe from Lambda expression for Groovy 3, click h
ameter with
>>>> > parentheses: (e) -> e.
>>>> >
>>>> >*Here are some examples for lambda expression for Groovy:*
>>>> > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e)
>>>> -&g
n it would be no problem if it is
recognized as Closure if that is more easy to accomplish.
bye Jochen
If you reply to this email, your message will be added to the
discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-
l, your message will be added to the
discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736171.html
To unsubscribe from Lambda expression for Groovy 3, click here.
NAML
<http://groovy.329449.n5.nabble.com/template/NamlSer
On Tue, Oct 18, 2016 at 4:15 PM, Jesper Steen Møller
wrote:
> "Real lambdas" with the full invokedynamic treatment is a big job, and
> requires static type inference.
> Given that Groovy can already coerce closures into functional interfaces
> (dynamically), we could implement the whole metafactor
>>> > *Java8* allows parentheses-less parameter for lambda when the
>>>>> parameter is
>>>>> > single and without type: e -> e, but *Groovy* only allows
>>>>> parameter with
>>>>> > parentheses: (e) -> e
; e.
>>>> >
>>>> >*Here are some examples for lambda expression for Groovy:*
>>>> > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e)
>>>> -> r + e)
>>>>
>>>> which means
e.
>>> >
>>> >*Here are some examples for lambda expression for
>Groovy:*
>>> > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0,
>(r, e)
>>> -> r + e)
>>>
>>> which means you cannot write
>>> > assert 9 == [1, 2, 3].stream().map(e -&g
gt; > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e)
>> -> r + e)
>>
>> which means you cannot write
>> > assert 9 == [1, 2, 3].stream().map(e -> e + 1).reduce(0, (r, e)
>> -> r + e)
>>
>>
I find not so ok. Here again it would be no problem if it is
recognized as Closure if that is more easy to accomplish.
bye Jochen
If you reply to this email, your message will be added to the
discussio
your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736171.html
To unsubscribe from Lambda expression for Groovy 3, click
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&nod
which I find not so ok. Here again it would be no problem if it is
recognized as Closure if that is more easy to accomplish.
bye Jochen
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Lambda-express
On 17.10.2016 17:40, daniel_sun wrote:
Hi all,
Lambda expression for Groovy has been completed with a little
limitation, which is due to the existing closure whose parameter list can be
ambiguous to lambda expression, e.g. {a -> a} which can be parsed as a
lambda expression in a block,
s,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
39 matches
Mail list logo
