Re: [VOTE] new operator ?=

2016-11-23 Thread Leo Bartoloni 
+1

Il 24 nov 2016 1:30 AM, "Daniel Sun"  ha scritto:

> I like the nickname "Elvis assignment" for ?=
>
> Cheers,
> Daniel.Sun
>
>
>
> 在 2016年11月24日 04:18，"Guillaume Laforge [via Groovy]"  email] >写道： type="att
> Sounds about right.
>
> On Wed, Nov 23, 2016 at 9:07 PM, Shil Sinha <[hidden email]
> > wrote:
>
>> Elvis assignment?
>>
>> On Wed, Nov 23, 2016 at 1:47 PM Andres Almiray <[hidden email]
>> > wrote:
>>
>>> Long live pompaduor walrus ...
>>>
>>> What would be an appropriate nickname for ?=, I wonder.
>>>
>>> ---
>>> Java Champion; Groovy Enthusiast
>>> http://jroller.com/aalmiray
>>> http://www.linkedin.com/in/aalmiray
>>> --
>>> What goes up, must come down. Ask any system administrator.
>>> There are 10 types of people in the world: Those who understand binary,
>>> and those who don't.
>>> To understand recursion, we must first understand recursion.
>>>
>>> On Wed, Nov 23, 2016 at 7:35 PM, Paul King <[hidden email]
>>> > wrote:
>>>
>>> For all our other operators of the form:
>>>
>>> a X= b
>>>
>>> it is shorthand for:
>>>
>>> a = a X b
>>>
>>> So, to follow that convention the operator is:
>>>
>>> a ?:= b
>>>
>>> which as per previous discussions is a bit cumbersome, so I am +1 for
>>> the shortened form so long as we document appropriately.
>>>
>>> Paul.
>>>
>>>
>>> On Thu, Nov 24, 2016 at 3:54 AM, Gerald Wiltse <[hidden email]
>>> > wrote:
>>> > +1
>>> >
>>> > Gerald R. Wiltse
>>> > [hidden email] 
>>> >
>>> >
>>> > On Wed, Nov 23, 2016 at 12:28 PM, Winnebeck, Jason
>>> > <[hidden email]
>>> > wrote:
>>> >>
>>> >> At first I was going to vote 0, because I feel like a = a ?: b is
>>> clear
>>> >> (and I compare it to a = a || b from JS). However, looking at the dev
>>> list,
>>> >> I definitely see a nice case for it:
>>> >>
>>> >> person.name.last = person.name.last ?: "unknown"
>>> >>
>>> >> When you have a non-trivial assignment expression, I see the benefit:
>>> >>
>>> >> person.name.last ?= "unknown"
>>> >>
>>> >> However, I feel like it is not intuitive or clear. But, I don't think
>>> the
>>> >> operator hurts, and it's certainly not any less intuitive than <=> for
>>> >> example or even ?: when seen for the very first time. It's an easy
>>> look up
>>> >> in Groovy docs, and if you don't know it and don't use it, it's not a
>>> huge
>>> >> loss. So it doesn't hurt to add it, and while not instantly readable,
>>> it's a
>>> >> trivial docs lookup when someone is reading the code.
>>> >>
>>> >> So, I vote +1. But, honestly, I don't see myself using it very often
>>> as
>>> >> I'd normally use Elvis at time of initial assignment. I wouldn't put
>>> it very
>>> >> high on a prioritized backlog of things to improve for Groovy.
>>> >>
>>> >> Jason
>>> >>
>>> >> -Original Message-
>>> >> From: Daniel Sun [mailto:[hidden email]
>>> ]
>>> >> Sent: Wednesday, November 23, 2016 10:59 AM
>>> >> To: [hidden email]
>>> 
>>> >> Subject: [VOTE] new operator ?=
>>> >>
>>> >> Hi all,
>>> >>
>>> >>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a =
>>> a ?:
>>> >> 'foo') were to be added to Groovy programming language, do you like
>>> it?
>>> >> (Yes: +1; No: -1; Not bad: 0)
>>> >>
>>> >> Cheers,
>>> >> Daniel.Sun
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >> http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
>>> >> Sent from the Groovy Users mailing list archive at Nabble.com.
>>> >>
>>> >> This email message and any attachments are for the sole use of the
>>> >> intended recipient(s). Any unauthorized review, use, disclosure or
>>> >> distribution is prohibited. If you are not the intended recipient,
>>> please
>>> >> contact the sender by reply email and destroy all copies of the
>>> original
>>> >> message and any attachments.
>>> >
>>> >
>>>
>>>
>>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://groovy.329449.n5.nabble.com/VOTE-new-operator-
> tp5736931p5736959.html
> To unsubscribe from [VOTE] new operator ?=, click here.
> NAML
>

Re: [VOTE] new operator ?=

2016-11-23 Thread Daniel Sun 
I like the nickname "Elvis assignment" for ?=

Cheers,
Daniel.Sun



在 2016年11月24日 04:18，"Guillaume Laforge [via Groovy]" 
写道：http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and 
those who don't.
To understand recursion, we must first understand recursion.

On Wed, Nov 23, 2016 at 7:35 PM, Paul King <[hidden 
email]> wrote:
For all our other operators of the form:

a X= b

it is shorthand for:

a = a X b

So, to follow that convention the operator is:

a ?:= b

which as per previous discussions is a bit cumbersome, so I am +1 for
the shortened form so long as we document appropriately.

Paul.


On Thu, Nov 24, 2016 at 3:54 AM, Gerald Wiltse <[hidden 
email]> wrote:
> +1
>
> Gerald R. Wiltse
> [hidden email]
>
>
> On Wed, Nov 23, 2016 at 12:28 PM, Winnebeck, Jason
> <[hidden email]> wrote:
>>
>> At first I was going to vote 0, because I feel like a = a ?: b is clear
>> (and I compare it to a = a || b from JS). However, looking at the dev list,
>> I definitely see a nice case for it:
>>
>> person.name.last = person.name.last ?: "unknown"
>>
>> When you have a non-trivial assignment expression, I see the benefit:
>>
>> person.name.last ?= "unknown"
>>
>> However, I feel like it is not intuitive or clear. But, I don't think the
>> operator hurts, and it's certainly not any less intuitive than <=> for
>> example or even ?: when seen for the very first time. It's an easy look up
>> in Groovy docs, and if you don't know it and don't use it, it's not a huge
>> loss. So it doesn't hurt to add it, and while not instantly readable, it's a
>> trivial docs lookup when someone is reading the code.
>>
>> So, I vote +1. But, honestly, I don't see myself using it very often as
>> I'd normally use Elvis at time of initial assignment. I wouldn't put it very
>> high on a prioritized backlog of things to improve for Groovy.
>>
>> Jason
>>
>> -Original Message-
>> From: Daniel Sun [mailto:[hidden 
>> email]]
>> Sent: Wednesday, November 23, 2016 10:59 AM
>> To: [hidden email]
>> Subject: [VOTE] new operator ?=
>>
>> Hi all,
>>
>>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
>> 'foo') were to be added to Groovy programming language, do you like it?
>> (Yes: +1; No: -1; Not bad: 0)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context:
>> http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>> This email message and any attachments are for the sole use of the
>> intended recipient(s). Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient, please
>> contact the sender by reply email and destroy all copies of the original
>> message and any attachments.
>
>




--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge / 
Google+



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931p5736959.html
To unsubscribe from [VOTE] new operator ?=, click 
here.
NAML




--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931p5736970.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: [VOTE] new operator ?=

2016-11-23 Thread Gerald Wiltse 
+1

Gerald R. Wiltse
jerrywil...@gmail.com


On Wed, Nov 23, 2016 at 12:28 PM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> At first I was going to vote 0, because I feel like a = a ?: b is clear
> (and I compare it to a = a || b from JS). However, looking at the dev list,
> I definitely see a nice case for it:
>
> person.name.last = person.name.last ?: "unknown"
>
> When you have a non-trivial assignment expression, I see the benefit:
>
> person.name.last ?= "unknown"
>
> However, I feel like it is not intuitive or clear. But, I don't think the
> operator hurts, and it's certainly not any less intuitive than <=> for
> example or even ?: when seen for the very first time. It's an easy look up
> in Groovy docs, and if you don't know it and don't use it, it's not a huge
> loss. So it doesn't hurt to add it, and while not instantly readable, it's
> a trivial docs lookup when someone is reading the code.
>
> So, I vote +1. But, honestly, I don't see myself using it very often as
> I'd normally use Elvis at time of initial assignment. I wouldn't put it
> very high on a prioritized backlog of things to improve for Groovy.
>
> Jason
>
> -Original Message-
> From: Daniel Sun [mailto:realblue...@hotmail.com]
> Sent: Wednesday, November 23, 2016 10:59 AM
> To: us...@groovy.incubator.apache.org
> Subject: [VOTE] new operator ?=
>
> Hi all,
>
>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
> 'foo') were to be added to Groovy programming language, do you like it?
> (Yes: +1; No: -1; Not bad: 0)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-new-operator-tp5736931.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

RE: [VOTE] new operator ?=

2016-11-23 Thread Winnebeck, Jason 
At first I was going to vote 0, because I feel like a = a ?: b is clear (and I 
compare it to a = a || b from JS). However, looking at the dev list, I 
definitely see a nice case for it:

person.name.last = person.name.last ?: "unknown"

When you have a non-trivial assignment expression, I see the benefit:

person.name.last ?= "unknown"

However, I feel like it is not intuitive or clear. But, I don't think the 
operator hurts, and it's certainly not any less intuitive than <=> for example 
or even ?: when seen for the very first time. It's an easy look up in Groovy 
docs, and if you don't know it and don't use it, it's not a huge loss. So it 
doesn't hurt to add it, and while not instantly readable, it's a trivial docs 
lookup when someone is reading the code.

So, I vote +1. But, honestly, I don't see myself using it very often as I'd 
normally use Elvis at time of initial assignment. I wouldn't put it very high 
on a prioritized backlog of things to improve for Groovy.

Jason

-Original Message-
From: Daniel Sun [mailto:realblue...@hotmail.com] 
Sent: Wednesday, November 23, 2016 10:59 AM
To: us...@groovy.incubator.apache.org
Subject: [VOTE] new operator ?=

Hi all,

 If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
'foo') were to be added to Groovy programming language, do you like it?
(Yes: +1; No: -1; Not bad: 0)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
Sent from the Groovy Users mailing list archive at Nabble.com.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: [VOTE] new operator ?=

2016-11-23 Thread Clayton Long 
+1
I like it.

Thanks,

Clayton
Sent from my smartphone;
Please excuse any misspellings

> On Nov 23, 2016, at 10:59 AM, Daniel Sun  wrote:
> 
> Hi all,
> 
> If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
> 'foo') were to be added to Groovy programming language, do you like it?
> (Yes: +1; No: -1; Not bad: 0)
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
> Sent from the Groovy Users mailing list archive at Nabble.com.

Re: [VOTE] new operator ?=

2016-11-23 Thread Edgar Harutyunyan 
+1

On 11/23/2016 08:07 PM, Søren Berg Glasius (GR8Conf EU) wrote:
> +1
> 
> Best regards,
> Søren Berg Glasius
> GR8Conf Europe organizing team
> 
> GR8Conf ApS
> Mobile: +45 40 44 91 88, Web: www.gr8conf.eu ,
> Skype: sbglasius 
> Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
> Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> --- GR8Conf - Dedicated to the Groovy Ecosystem
> 
> From: Daniel Sun  
> Reply: users@groovy.apache.org 
>  
> Date: 23. november 2016 at 16.59.10
> To: us...@groovy.incubator.apache.org
> 
> 
> 
> Subject: [VOTE] new operator ?=
> 
>> Hi all,
>>
>> If the new operator ?= (e.g. a ?= 'foo' is equivalent of a = a ?:
>> 'foo') were to be added to Groovy programming language, do you like it?
>> (Yes: +1; No: -1; Not bad: 0)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> -- 
>> View this message in context:
>> http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.

-- 
Kind Regards,
Edgar

Re: [VOTE] new operator ?=

2016-11-23 Thread Jim Northrop 
Yes, more use cases please. 

Sent from my iPad

> On 23 Nov 2016, at 17:00, Abhinav Sharma  wrote:
> 
> Well, you need to give more use cases for this one
> 
>> On Nov 23, 2016 9:29 PM, "Daniel Sun"  wrote:
>> Hi all,
>> 
>>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
>> 'foo') were to be added to Groovy programming language, do you like it?
>> (Yes: +1; No: -1; Not bad: 0)
>> 
>> Cheers,
>> Daniel.Sun
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.

Re: [VOTE] new operator ?=

2016-11-23 Thread Abhinav Sharma 
+1
On Nov 23, 2016 10:19 PM, "Dierk König"  wrote:

> +1
>
> > Am 23.11.2016 um 16:59 schrieb Daniel Sun :
> >
> > Hi all,
> >
> > If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
> > 'foo') were to be added to Groovy programming language, do you like it?
> > (Yes: +1; No: -1; Not bad: 0)
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> > --
> > View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-new-operator-tp5736931.html
> > Sent from the Groovy Users mailing list archive at Nabble.com.
>
>

Re: [VOTE] new operator ?=

2016-11-23 Thread Andres Almiray 
+1

---
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Wed, Nov 23, 2016 at 4:59 PM, Daniel Sun  wrote:

> Hi all,
>
>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
> 'foo') were to be added to Groovy programming language, do you like it?
> (Yes: +1; No: -1; Not bad: 0)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-new-operator-tp5736931.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: [VOTE] new operator ?=

2016-11-23 Thread GR8Conf EU 
+1

Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team

GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu, Skype: sbglasius
Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem

From: Daniel Sun  
Reply: users@groovy.apache.org 

Date: 23. november 2016 at 16.59.10
To: us...@groovy.incubator.apache.org 

Subject:  [VOTE] new operator ?=

Hi all,

If the new operator ?= (e.g. a ?= 'foo' is equivalent of a = a ?:
'foo') were to be added to Groovy programming language, do you like it?
(Yes: +1; No: -1; Not bad: 0)

Cheers,
Daniel.Sun



-- 
View this message in context:
http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: [VOTE] new operator ?=

2016-11-23 Thread David Dawson 
+1



On 23 November 2016 at 16:01, Guillaume Laforge  wrote:

> There's more context in that thread here:
> http://www.groovy-lang.org/mailing-lists.html
>
> On Wed, Nov 23, 2016 at 5:00 PM, Abhinav Sharma 
> wrote:
>
>> Well, you need to give more use cases for this one
>> On Nov 23, 2016 9:29 PM, "Daniel Sun"  wrote:
>>
>>> Hi all,
>>>
>>>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
>>> 'foo') were to be added to Groovy programming language, do you like it?
>>> (Yes: +1; No: -1; Not bad: 0)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> View this message in context: http://groovy.329449.n5.nabble
>>> .com/VOTE-new-operator-tp5736931.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>



-- 


David Dawson | CEO | Simplicity Itself

Tel +44 7866 011 256
Skype: davidadawson
david.daw...@simplicityitself.com
http://www.simplicityitself.com

Re: [VOTE] new operator ?=

2016-11-23 Thread Guillaume Laforge 
Roh, let me fix the link:
http://groovy.329449.n5.nabble.com/PROPOSAL-new-operator-tp5736886.html

On Wed, Nov 23, 2016 at 5:01 PM, Guillaume Laforge 
wrote:

> There's more context in that thread here:
> http://www.groovy-lang.org/mailing-lists.html
>
> On Wed, Nov 23, 2016 at 5:00 PM, Abhinav Sharma 
> wrote:
>
>> Well, you need to give more use cases for this one
>> On Nov 23, 2016 9:29 PM, "Daniel Sun"  wrote:
>>
>>> Hi all,
>>>
>>>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
>>> 'foo') were to be added to Groovy programming language, do you like it?
>>> (Yes: +1; No: -1; Not bad: 0)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> View this message in context: http://groovy.329449.n5.nabble
>>> .com/VOTE-new-operator-tp5736931.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

Re: [VOTE] new operator ?=

2016-11-23 Thread Guillaume Laforge 
Yes, +1 :-)

On Wed, Nov 23, 2016 at 4:59 PM, Daniel Sun  wrote:

> Hi all,
>
>  If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
> 'foo') were to be added to Groovy programming language, do you like it?
> (Yes: +1; No: -1; Not bad: 0)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-new-operator-tp5736931.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

RE: JDK8 Streams / Closure cast to interface

2016-11-23 Thread Winnebeck, Jason 
It sounds like a good idea to support Java lambda syntax, or at least provide a 
way in Groovy to use Java lambdas. The only concern I have is that I still 
think the closure syntax is better, since you don't have parenthesis overload, 
and I still like the curly braces to distinguish that we are changing from a 
"parameter passing" context to an "expression" context. To be the lambda single 
expression syntax looks too much like parameter passing rather than defining a 
lambda.

stream.forEach((it) -> System.out.println(it))

stream.forEach{ System.out.println(it) }

I agree with Jochen about not having to create the Closure, if that is an 
option that sounds great. At first I thought it would be an observable (and 
therefore potentially breaking) change because the class would extend Closure, 
but then I realize when you pass a closure to a SAM method, the getClass is a 
java.lang.reflect.Proxy subclass instance. I have a hard time thinking that 
users would call Proxy.isProxyClass on the result, but who knows. But, I wonder 
if that potential breakage is worth it if Groovy could replace the closure that 
does not escape with a non-closure lambda (Java 8+) or non-closure inner class 
(Java 7 and earlier) when in static compilation mode. Since we know that the 
closure is to be assigned to a non-Closure type, we know setDelegate/setOwner 
can't be called, nor can setResolveStrategy. That situation should enable the 
Groovy static compiler to know whether or not use of Closure is required.

I think it's possible only under static compiler, because in dynamic mode, the 
runtime type, metaclass or runtime extension method could introduce an overload 
of the same method that takes Closure. I think only the static compiler can 
guarantee that the closure can be replaced with non-closure type without 
changing semantics (other than the change of getClass from proxy to something 
else).

Jason

-Original Message-
From: Graeme Rocher [mailto:graeme.roc...@gmail.com] 
Sent: Wednesday, November 23, 2016 6:18 AM
To: users@groovy.apache.org
Subject: Re: JDK8 Streams / Closure cast to interface

Jochen said - “If you want this really efficient, you have to skip the 
generation of the Groovy Closure instance. This is doable and I plan to do 
this, but it will be a breaking change (all open blocks would be realised using 
the same class for example, having that instance would even become optional).”

Could I recommend that since the new parser now supports the lambda syntax that 
we add to Groovy the optimised version for lambdas and keep the closure 
behaviour as is to avoid a breaking change?

This would mean that there is a visual syntactical difference between closures 
and lambdas and the behaviour of lambdas will be closer to Java thus not 
surprising folks coming from Java.

We could then keep the behaviour of closures the same as it is now without it 
being a breaking change.

Thoughts?

On Wed, Nov 23, 2016 at 11:11 AM, Jochen Theodorou  wrote:
>
>
> On 22.11.2016 19:37, Winnebeck, Jason wrote:
>>
>> I was referring to a compile-time generation of the class -- that the 
>> Closure itself that is normally generated implements the interface natively.
>
>
> Which means we are talking about direct assignments to local variables only?
> I mean the static compiler can do that in more cases, but frankly, why 
> should the static compiler even bother with creating a Closure?
>
>> That would make it equivalent to anonymous class in Java 7 and 
>> earlier for calling functional (or any SAM type) methods. That 
>> wouldn't have any problems on Android, and should be as efficient as Java 
>> without lambdas?
>
>
> Android is ok, yes. As efficient as Java without lambdas... well.. 
> that I am not sure of. Even if you make it as an anonymous inner class 
> that implements the interface and extends Closure, even if the 
> interface method will just call doCall, you will still have to pay the 
> initialization cost of the Closure, and Closure will inspect itself to 
> set the maximum parameter number for example, you will still request a meta 
> class and do some other things.
> So the init would not be as efficient. The method invocation should be 
> similar to Java, if done from Java then, since there is no dynamic 
> call. So here you would gain over todays Closure.
>
> But for typical usages of non-static Groovy the gain would be almost nil.
> Unless we can lift restrictions
>
>> I would assume the interface's method delegating to doCall would get 
>> inlined. In other words, Groovy generating code like:
>>
>> class X {
>> public static void main(String[] args) {
>> Stream.of(1).forEach(new x__closure1(X.class, X.class));
>> }
>>
>> private static class x__closure1 extends Closure 
>> implements Consumer {
>> public x__closure1(Object owner, Object thisObject) {
>> super(owner, thisObject);
>> }
>>

Re: JDK8 Streams / Closure cast to interface

2016-11-23 Thread Jochen Theodorou 



On 22.11.2016 19:37, Winnebeck, Jason wrote:

I was referring to a compile-time generation of the class -- that the Closure 
itself that is normally generated implements the interface natively.


Which means we are talking about direct assignments to local variables 
only? I mean the static compiler can do that in more cases, but frankly, 
why should the static compiler even bother with creating a Closure?



That would make it equivalent to anonymous class in Java 7 and earlier for 
calling functional (or any SAM type) methods. That wouldn't have any problems 
on Android, and should be as efficient as Java without lambdas?


Android is ok, yes. As efficient as Java without lambdas... well.. that 
I am not sure of. Even if you make it as an anonymous inner class that 
implements the interface and extends Closure, even if the interface 
method will just call doCall, you will still have to pay the 
initialization cost of the Closure, and Closure will inspect itself to 
set the maximum parameter number for example, you will still request a 
meta class and do some other things. So the init would not be as 
efficient. The method invocation should be similar to Java, if done from 
Java then, since there is no dynamic call. So here you would gain over 
todays Closure.


But for typical usages of non-static Groovy the gain would be almost 
nil. Unless we can lift restrictions



I would assume the interface's method delegating to doCall would get inlined. 
In other words, Groovy generating code like:

class X {
public static void main(String[] args) {
Stream.of(1).forEach(new x__closure1(X.class, X.class));
}

private static class x__closure1 extends Closure implements 
Consumer {
public x__closure1(Object owner, Object thisObject) {
super(owner, thisObject);
}

void doCall(Integer x) {
System.out.println(x);
}

@Override
public void accept(Integer x) {
doCall(x);
}
}
}

From Groovy: Stream.of(1).forEach { println it }

The new part being that Groovy added the accept method and implements to the 
closure it already normally would have generated, and castToType would not need 
to be called. All of the code manipulation is done at compile-time so it is 
fully STC and Android compatible, and no reflection is in use. You still have 
the a little more overhead of Closure object compared to Java static inner 
class, but I imagine this must be a lot less than proxy, but still allows 
Closure to use the owner/delegate patterns that Groovy is known for, and I 
assume would not affect backwards compatibility as superclass stays Closure.

Of course, if it were possible for compiler to determine that the closure is never using owner, delegate, or 
"thisObject", then it could be possible to drop the "extends Closure" entirely if it can 
be proven that the "closureness" of the object can never be observed. But that's likely not 
possible as any method taking an interface could choose to check for instanceof Closure and/or cast or do 
something special if Groovy closure is passed in -- although is that even possible today since Groovy 
actually passes in a proxy?


It depends on if the implicit "this" is used or not. { println it } uses 
implicit this, thus cannot do it for sure. { this.println it }, no 
implicit, thus can be optimized.


I am wondering what would happen if we had 2 versions, one with implicit 
this delegation logic, the other not. Because if the usage is just an 
appended block and the target is just a functional interface, you will 
not need the version with delegate.


bye Jochen