date:20190217

Re: DGM for first or default

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

Thanks for the note on 2.5 and the v8 methods.


I considered withDefault, but yes the mutation was a deal breaker and it only 
works for List and Map.  If I use Optional, then the case of null as a member 
of the collection becomes an issue to deal with.  Adding a bevy of new DGMs is 
not ideal either.  This is a tough one; I might end up sticking with "iterable 
? iterable.first() : defaultValue" for now.


I would like to submit for future consideration that it would be nice to be 
able to control getAt's choice to return null if the given index is out of 
range.  This to me is the more general solution.


From: Paul King 
Sent: Sunday, February 17, 2019 6:07 PM
To: Groovy_Developers
Subject: Re: DGM for first or default

Groovy 2.5 still has JDK 7 as minimum whereas Groovy 3.0 has 8 as minimum. You 
can still add DGM methods into 
org.codehaus.groovy.vmplugin.v8.PluginDefaultGroovyMethods and then they will 
only be available when running on a JDK8+ VM.

Wrt to the question of whether we should have firstOrElse, lastOrElse, 
getAtOrElse, etc., it is certainly a possibility to add such a whole myriad of 
duplicated methods but there might be better alternatives. Does the existing 
ListWtihDefault work for you? It does mutate which might not be what you are 
after but perhaps we could create an alternative variant of that.

Cheers, Paul.


On Mon, Feb 18, 2019 at 7:36 AM Milles, Eric (TR Tech, Content & Ops) 
mailto:eric.mil...@thomsonreuters.com>> wrote:

When I first worked all this up my target was Groovy 2.4.  If that is raised to 
Groovy 2.5+ I just started to wonder if java.util.Optional could be leveraged 
for an improved solution.  I also remembered some feedback some time ago from 
MG where to no-arg call would be "getName()" so that it could be used in Groovy 
sources as "name".  Then if there were versions with more arguments, they would 
be "name(arg1, arg2, ...)".


So if I were to implement new DGMs in a vacuum, would something like this make 
sense?


public static  Optional getFirst(Iterable self)

public static  Optional getFirst(List self)

public static  Optional getFirst(T[] self)
public static  Optional getFirst(org.codehaus.groovy.runtime.NullObject 
self)

This could be used like "list.first.orElse(defaultValue)".  Now that I write 
that out, I can see the conflict with list spread shorthand.  Darn, I wish that 
didn't exist and you had to explicitly use "list*.prop".


General question: Are there limitations to using Java 8 stuff in Groovy core?  
I'm not sure how Android support comes into play here.



From: Milles, Eric (TR Tech, Content & Ops) 
mailto:eric.mil...@thomsonreuters.com>>
Sent: Sunday, February 17, 2019 1:56 PM
To: dev@groovy.apache.org
Subject: Re: DGM for first or default


I'd like to restart this discussion.  I'm not sure if this should move to new 
JIRA ticket or Pull Request.  There are a few open questions I'd like to get 
some feedback on.  I have managed to solve the problem of getting from a null 
array/iterable.


My use case is getting the first item from an iterable or else a supplied 
default.  Alternate proposals like "list?.first() ?: defaultValue" or 
"list?.find() ?: defaultValue" do not properly handle all use cases.  It took 
quite a number of tries to figure it out.


"list ? list.first() : defaultValue" appears to be roughly equivalent.  
However, having the additional DGMs would mean a one-time check for non-null, 
non-empty and elimination of repeated "list", which may be a more complicated 
expression.  And in rare cases, a type could extend Iterable and provide a 
non-standard implementation of asBoolean().



Proposed additions to DefaultGroovyMethods:


public static  T firstOrElse(Iterable self, T defaultValue)

public static  T firstOrElse(List self, T defaultValue) // allows use of 
isEmpty() and get(i) instead of creating an Iterator instance

public static  T firstOrElse(T[] self, T defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, T 
defaultValue) // exists solely for the (null).firstOrDefault(value) case


public static  T firstOrElse(Iterable self, Supplier defaultValue)

public static  T firstOrElse(List self, Supplier defaultValue)

public static  T firstOrElse(T[] self, Supplier defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, 
Supplier defaultValue)

Since this is targeted at Groovy 2.5+ I have selected 
java.util.function.Supplier instead of groovy.lang.Closure.  Although that 
could be changed if a new Groovy 2.4 minor release was planned.


Usage:
  Iterable iterable = null
  println iterable.firstOrElse('default') // prints 'default'

  iterable = []
  println iterable.firstOrElse('default') // prints 'default'

  iterable = [0]
  println iterable.firstOrElse('default') // prints 0

  iterable = [null]
  println iterable.firstOrElse('default') //

Re: DGM for first or default

2019-02-17 Thread Paul King

Groovy 2.5 still has JDK 7 as minimum whereas Groovy 3.0 has 8 as minimum.
You can still add DGM methods
into org.codehaus.groovy.vmplugin.v8.PluginDefaultGroovyMethods and then
they will only be available when running on a JDK8+ VM.

Wrt to the question of whether we should have firstOrElse, lastOrElse,
getAtOrElse, etc., it is certainly a possibility to add such a whole myriad
of duplicated methods but there might be better alternatives. Does the
existing ListWtihDefault work for you? It does mutate which might not be
what you are after but perhaps we could create an alternative variant of
that.

Cheers, Paul.


On Mon, Feb 18, 2019 at 7:36 AM Milles, Eric (TR Tech, Content & Ops) <
eric.mil...@thomsonreuters.com> wrote:

> When I first worked all this up my target was Groovy 2.4.  If that is
> raised to Groovy 2.5+ I just started to wonder if java.util.Optional
> could be leveraged for an improved solution.  I also remembered some
> feedback some time ago from MG where to no-arg call would be "getName()" so
> that it could be used in Groovy sources as "name".  Then if there were
> versions with more arguments, they would be "name(arg1, arg2, ...)".
>
>
> So if I were to implement new DGMs in a vacuum, would something like this
> make sense?
>
>
> public static  Optional getFirst(Iterable self)
>
> public static  Optional getFirst(List self)
> public static  Optional getFirst(T[] self)
> public static  Optional getFirst(
> org.codehaus.groovy.runtime.NullObject self)
>
>
> This could be used like "list.first.orElse(defaultValue)".  Now that I
> write that out, I can see the conflict with list spread shorthand.  Darn, I
> wish that didn't exist and you had to explicitly use "list*.prop".
>
>
> *General question: *Are there limitations to using Java 8 stuff in Groovy
> core?  I'm not sure how Android support comes into play here.
>
>
> --
> *From:* Milles, Eric (TR Tech, Content & Ops) <
> eric.mil...@thomsonreuters.com>
> *Sent:* Sunday, February 17, 2019 1:56 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: DGM for first or default
>
>
> I'd like to restart this discussion.  I'm not sure if this should move to
> new JIRA ticket or Pull Request.  There are a few open questions I'd like
> to get some feedback on.  I have managed to solve the problem of getting
> from a null array/iterable.
>
>
> My use case is getting the first item from an iterable or else a supplied
> default.  Alternate proposals like "list?.first() ?: defaultValue" or
> "list?.find() ?: defaultValue" do not properly handle all use cases.  It
> took quite a number of tries to figure it out.
>
>
> "list ? list.first() : defaultValue" appears to be roughly equivalent.
> However, having the additional DGMs would mean a one-time check for
> non-null, non-empty and elimination of repeated "list", which may be a more
> complicated expression.  And in rare cases, a type could extend Iterable and
> provide a non-standard implementation of asBoolean().
>
>
>
> *Proposed additions to DefaultGroovyMethods:*
>
>
> public static  T firstOrElse(Iterable self, T defaultValue)
>
> public static  T firstOrElse(List self, T defaultValue) // allows
> use of isEmpty() and get(i) instead of creating an Iterator instance
>
> public static  T firstOrElse(T[] self, T defaultValue)
>
> public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject
> self, T defaultValue) // exists solely for the (null).firstOrDefault(value)
> case
>
> public static  T firstOrElse(Iterable self, Supplier defaultValue
> )
>
> public static  T firstOrElse(List self, Supplier defaultValue)
>
> public static  T firstOrElse(T[] self, Supplier defaultValue)
>
> public static  T
> firstOrElse(org.codehaus.groovy.runtime.NullObject self, Supplier
> defaultValue)
>
> Since this is targeted at Groovy 2.5+ I have selected
> java.util.function.Supplier instead of groovy.lang.Closure.  Although that
> could be changed if a new Groovy 2.4 minor release was planned.
>
>
> *Usage:*
>   Iterable iterable = null
>   println iterable.firstOrElse('default') // prints 'default'
>
>   iterable = []
>   println iterable.firstOrElse('default') // prints 'default'
>
>   iterable = [0]
>   println iterable.firstOrElse('default') // prints 0
>
>   iterable = [null]
>   println iterable.firstOrElse('default') // prints null
>
>   iterable = [false]
>   println iterable.firstOrElse('default') // prints false
>
>   iterable = null
>   iterable.firstOrElse { -> throw new ExceptionOfMyChoosing() } // throws
>
>
>
> *Open items:*
>
>
>1. Should a set of methods "lastOrElse" also be created?  It would not
>take much effort to add them at the same time.
>2. Should the "getAt" methods be similarly extended, like "public
>static  T getAt(List self, int idx, T defaultValue)", etc.
>3. If "getAt" is extended in this way, would it be useful to also
>consider extending the "[idx]" syntax form of "getAt" to include the
>default?
>4. There was a question

Re: DGM for first or default

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

When I first worked all this up my target was Groovy 2.4.  If that is raised to 
Groovy 2.5+ I just started to wonder if java.util.Optional could be leveraged 
for an improved solution.  I also remembered some feedback some time ago from 
MG where to no-arg call would be "getName()" so that it could be used in Groovy 
sources as "name".  Then if there were versions with more arguments, they would 
be "name(arg1, arg2, ...)".


So if I were to implement new DGMs in a vacuum, would something like this make 
sense?


public static  Optional getFirst(Iterable self)

public static  Optional getFirst(List self)

public static  Optional getFirst(T[] self)
public static  Optional getFirst(org.codehaus.groovy.runtime.NullObject 
self)

This could be used like "list.first.orElse(defaultValue)".  Now that I write 
that out, I can see the conflict with list spread shorthand.  Darn, I wish that 
didn't exist and you had to explicitly use "list*.prop".


General question: Are there limitations to using Java 8 stuff in Groovy core?  
I'm not sure how Android support comes into play here.



From: Milles, Eric (TR Tech, Content & Ops) 
Sent: Sunday, February 17, 2019 1:56 PM
To: dev@groovy.apache.org
Subject: Re: DGM for first or default


I'd like to restart this discussion.  I'm not sure if this should move to new 
JIRA ticket or Pull Request.  There are a few open questions I'd like to get 
some feedback on.  I have managed to solve the problem of getting from a null 
array/iterable.


My use case is getting the first item from an iterable or else a supplied 
default.  Alternate proposals like "list?.first() ?: defaultValue" or 
"list?.find() ?: defaultValue" do not properly handle all use cases.  It took 
quite a number of tries to figure it out.


"list ? list.first() : defaultValue" appears to be roughly equivalent.  
However, having the additional DGMs would mean a one-time check for non-null, 
non-empty and elimination of repeated "list", which may be a more complicated 
expression.  And in rare cases, a type could extend Iterable and provide a 
non-standard implementation of asBoolean().



Proposed additions to DefaultGroovyMethods:


public static  T firstOrElse(Iterable self, T defaultValue)

public static  T firstOrElse(List self, T defaultValue) // allows use of 
isEmpty() and get(i) instead of creating an Iterator instance

public static  T firstOrElse(T[] self, T defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, T 
defaultValue) // exists solely for the (null).firstOrDefault(value) case


public static  T firstOrElse(Iterable self, Supplier defaultValue)

public static  T firstOrElse(List self, Supplier defaultValue)

public static  T firstOrElse(T[] self, Supplier defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, 
Supplier defaultValue)

Since this is targeted at Groovy 2.5+ I have selected 
java.util.function.Supplier instead of groovy.lang.Closure.  Although that 
could be changed if a new Groovy 2.4 minor release was planned.


Usage:
  Iterable iterable = null
  println iterable.firstOrElse('default') // prints 'default'

  iterable = []
  println iterable.firstOrElse('default') // prints 'default'

  iterable = [0]
  println iterable.firstOrElse('default') // prints 0

  iterable = [null]
  println iterable.firstOrElse('default') // prints null

  iterable = [false]
  println iterable.firstOrElse('default') // prints false

  iterable = null
  iterable.firstOrElse { -> throw new ExceptionOfMyChoosing() } // throws



Open items:


  1.  Should a set of methods "lastOrElse" also be created?  It would not take 
much effort to add them at the same time.
  2.  Should the "getAt" methods be similarly extended, like "public static  
T getAt(List self, int idx, T defaultValue)", etc.
  3.  If "getAt" is extended in this way, would it be useful to also consider 
extending the "[idx]" syntax form of "getAt" to include the default?
  4.  There was a question raised: if "iterable" contains Closures or 
Suppliers, how should that case be handled?  I'm curious how often this might 
come up.




From: Milles, Eric (TR Technology & Ops) 
Sent: Friday, October 19, 2018 10:54 AM
To: dev@groovy.apache.org
Subject: Re: DGM for first or default


These may seem a bit simple for DGMs, but they do solve a couple problems as 
compared to "list ? list.first() ?: defaultValue".  First, no repetition of the 
"list" expression, which may be complex.  Second, content assist will show 
proposals for these methods.  Third, the Groovy truth problems with "list?[0] 
?: defaultValue", "list?.getAt(0) ?: defaultValue", "list.find() ?: 
defaultValue" and others do not exist for these.  If the first element is null 
or otherwise falsy, it will be returned as desired.  The only case for me that 
is unresolved is a null array or iterable.  In this case, Groovy throws "Cannot 
invoke method

Re: [editor/tooling support in core groovy]

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

There is also the possibility of a consolidated effort on a Language Server 
Protocol implementation for Groovy that would replace the current eclipse 
tooling upon reaching maturity.  This would extend to other platforms like 
Visual Studio Code as well.

From: Milles, Eric (TR Tech, Content & Ops) 
Sent: Sunday, February 17, 2019 2:06 PM
To: dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure

Agreed.  I'd be open to a side project to migrate eclipse patches back into 
core.  Many of them should be able to make the crossing.  There is also the 
possibility of conditional code with some sort of signal that it is the IDE, 
not the compiler or runtime.

There are a few other needs for the editor that the core would need to provide:

  1.  offsets, not just line and column for AST nodes
  2.  parser recovery so incomplete syntax in one method allows the rest to be 
parsed and compiled
  3.  remove assumptions of short-lived processes like compiler and allow for 
long-running processes like editor

From: Jochen Theodorou 
Sent: Sunday, February 17, 2019 1:17 PM
To: dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure

On 17.02.19 18:31, Milles, Eric (TR Tech, Content & Ops) wrote:
[...]
> So, parser recovery is new development.  And interpretation of new
> syntax in the absence of running all AST transforms to completion is new
> development.

and is there a way to make things more easy? I mean I would prefer to be
able to give eclipse an unmodified compiler - or at least one that does
not need to be source patched

bye Jochen

Re: [VOTE] Polish the generics type syntax for closure

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

Agreed.  I'd be open to a side project to migrate eclipse patches back into 
core.  Many of them should be able to make the crossing.  There is also the 
possibility of conditional code with some sort of signal that it is the IDE, 
not the compiler or runtime.

There are a few other needs for the editor that the core would need to provide:

  1.  offsets, not just line and column for AST nodes
  2.  parser recovery so incomplete syntax in one method allows the rest to be 
parsed and compiled
  3.  remove assumptions of short-lived processes like compiler and allow for 
long-running processes like editor

From: Jochen Theodorou 
Sent: Sunday, February 17, 2019 1:17 PM
To: dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure

On 17.02.19 18:31, Milles, Eric (TR Tech, Content & Ops) wrote:
[...]
> So, parser recovery is new development.  And interpretation of new
> syntax in the absence of running all AST transforms to completion is new
> development.

and is there a way to make things more easy? I mean I would prefer to be
able to give eclipse an unmodified compiler - or at least one that does
not need to be source patched

bye Jochen

Re: DGM for first or default

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

I'd like to restart this discussion.  I'm not sure if this should move to new 
JIRA ticket or Pull Request.  There are a few open questions I'd like to get 
some feedback on.  I have managed to solve the problem of getting from a null 
array/iterable.


My use case is getting the first item from an iterable or else a supplied 
default.  Alternate proposals like "list?.first() ?: defaultValue" or 
"list?.find() ?: defaultValue" do not properly handle all use cases.  It took 
quite a number of tries to figure it out.


"list ? list.first() : defaultValue" appears to be roughly equivalent.  
However, having the additional DGMs would mean a one-time check for non-null, 
non-empty and elimination of repeated "list", which may be a more complicated 
expression.  And in rare cases, a type could extend Iterable and provide a 
non-standard implementation of asBoolean().



Proposed additions to DefaultGroovyMethods:


public static  T firstOrElse(Iterable self, T defaultValue)

public static  T firstOrElse(List self, T defaultValue) // allows use of 
isEmpty() and get(i) instead of creating an Iterator instance

public static  T firstOrElse(T[] self, T defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, T 
defaultValue) // exists solely for the (null).firstOrDefault(value) case


public static  T firstOrElse(Iterable self, Supplier defaultValue)

public static  T firstOrElse(List self, Supplier defaultValue)

public static  T firstOrElse(T[] self, Supplier defaultValue)

public static  T firstOrElse(org.codehaus.groovy.runtime.NullObject self, 
Supplier defaultValue)

Since this is targeted at Groovy 2.5+ I have selected 
java.util.function.Supplier instead of groovy.lang.Closure.  Although that 
could be changed if a new Groovy 2.4 minor release was planned.


Usage:
  Iterable iterable = null
  println iterable.firstOrElse('default') // prints 'default'

  iterable = []
  println iterable.firstOrElse('default') // prints 'default'

  iterable = [0]
  println iterable.firstOrElse('default') // prints 0

  iterable = [null]
  println iterable.firstOrElse('default') // prints null

  iterable = [false]
  println iterable.firstOrElse('default') // prints false

  iterable = null
  iterable.firstOrElse { -> throw new ExceptionOfMyChoosing() } // throws



Open items:


  1.  Should a set of methods "lastOrElse" also be created?  It would not take 
much effort to add them at the same time.
  2.  Should the "getAt" methods be similarly extended, like "public static  
T getAt(List self, int idx, T defaultValue)", etc.
  3.  If "getAt" is extended in this way, would it be useful to also consider 
extending the "[idx]" syntax form of "getAt" to include the default?
  4.  There was a question raised: if "iterable" contains Closures or 
Suppliers, how should that case be handled?  I'm curious how often this might 
come up.




From: Milles, Eric (TR Technology & Ops) 
Sent: Friday, October 19, 2018 10:54 AM
To: dev@groovy.apache.org
Subject: Re: DGM for first or default


These may seem a bit simple for DGMs, but they do solve a couple problems as 
compared to "list ? list.first() ?: defaultValue".  First, no repetition of the 
"list" expression, which may be complex.  Second, content assist will show 
proposals for these methods.  Third, the Groovy truth problems with "list?[0] 
?: defaultValue", "list?.getAt(0) ?: defaultValue", "list.find() ?: 
defaultValue" and others do not exist for these.  If the first element is null 
or otherwise falsy, it will be returned as desired.  The only case for me that 
is unresolved is a null array or iterable.  In this case, Groovy throws "Cannot 
invoke method firstOrElse() on null obect" instead of running the method 
allowing null tolerance and return of default value.


public static  T firstOrElse(Iterable self, T defaultValue) {
Iterator iter = self.iterator();
if (iter.hasNext()) {
return iter.next();
}
return defaultValue;
}
public static  T firstOrElse(T[] self, T defaultValue) {
if (self.length > 0) {
return self[0];
}
return defaultValue;
}
// and similarly for the Closure (or java.util.function.Supplier if Java 8+ 
only) variants


Since safe navigation is being explored for by-index access, is there a 
possibility for including some for of "or supplied default" in any of the 
safe-navigation cases?  I personally find the new safe-indexing syntax to be 
unnecessary when "list?.getAt(i)" appears to be the equivalent to "list?[i]".


Alternate proposal, what if the DGM.getAt(self, int idx) had variants that 
included a default value return instead of hard-coded null?  Like this:

public static  T getAt(List self, int idx, T def) {
int size = self.size();
int i = normaliseIndex(idx, size);
if (i < size) {
return self.get(i);
} else {
//return null;

Re: [VOTE] Polish the generics type syntax for closure

2019-02-17 Thread MG


Just assumed you were thinking of languages that are widely used... ;-)
(Algol type languages are generally not particularily syntax-compatible 
with C-style languages in my book).


My suggestion was aimed at not introducing a new syntax variety to 
Groovy, while at the same time being more concise and being able to 
grasp the return type first.


Cheers,
mg

PS: I first encountered the generics syntax used by Java when it was 
introduced in C++, and it never felt alien to me. What syntax would you 
have used to add type parameters to types, given that parameter 
sequences are seperated with colons and all other types of brackets were 
already taken ?-)




On 17/02/2019 18:56, Jochen Theodorou wrote:

On 16.02.19 19:57, MG wrote:

Hi Daniel,

[...]
I assume Jochen's suggestion is coming from JavaScript/Kotlin, where 
the type of a function (method) is given after the colon.


there are many more than just those.

I think its readability is inferior to the C/C++/Java/... approach, 
and is only therefore suitable for often-not-typed languages such as 
JavaScript.


actually from several Pascal style languages like Modula2 or Ada. I 
think the C(++)/Java works well with a function name in between, but 
with just types and without the name it works better for me in the 
colon style.


Apart from it feeling alien to me in the Java/Groovy world, I fear 
next thing someone would suggest we introduce it into Groovy, which 
makes sense, "since we already use it in the Closure argument syntax"...


to be frank everything about generics is alien. It is just that people 
got used to it


bye Jochen

Re: [VOTE] Polish the generics type syntax for closure

2019-02-17 Thread Daniel.Sun

> It took me a lot of work to support @ClosureParams and @DelegatesTo in
Eclipse.  I'm not looking forward to doing it all over again.

The proposed syntax is actually a syntax sugar, which will be transformed to
the current code with annotations finally, so it should not result in much
rework ;-)

P.S. If the proposal is not accepted, it will be a good news for my son(4
years old), because I will have more time to play with him :-)

Cheers,
Daniel.Sun





-
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [VOTE] Polish the generics type syntax for closure

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

It's a -1 for me.  It took me a lot of work to support @ClosureParams and 
@DelegatesTo in Eclipse.  I'm not looking forward to doing it all over again.



72 hours is not enough time.  Monday is a US holiday, so many will not be at 
work and not checking emails.  You need to send these items out on Tuesdays so 
there is Wed-Fri for people to have a chance to review and ask questions.



From: Daniel.Sun 
Sent: Saturday, February 16, 2019 9:46 AM
To: d...@groovy.incubator.apache.org
Subject: [VOTE] Polish the generics type syntax for closure

Dear development community,

   I completed the GEP for polishing the generics type syntax for closure[1]
just now and happy to start the VOTE thread. The GEP is targeted for Groovy
3.0.0.

The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.

[ ] +1 Polish the generics type syntax for closure
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not polish the generics type syntax for closure because...

Cheers,
Daniel.Sun
[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GROOVY-2D8992=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=1IfyQ4a7ROEdJ4RmHuV1Z3Uc4HNoEnu08hpZVxfRfiQ=




-
Apache Groovy committer
Blog: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=so1mYDnsspDBvtPpTn5v62NLWBDJcsWhxEdJ0UuaRjY=
Twitter: @daniel_sun

--
Sent from: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=TBHY4GkPt16tD6tD5DJ2Mvx4ZBOLRGkRHlIh2tLSou4=

Re: [VOTE] Polish the generics type syntax for closure

2019-02-17 Thread Milles, Eric (TR Tech, Content & Ops)

I propose that new syntax ideas and bigger changes be brought to large 
conferences like Gr8 Conf so they can be discussed in a panel-style setting.  
This way there is likely to be knowledgeable Groovy enthusiasts available to 
work the idea through its initial stages.

From: Milles, Eric (TR Tech, Content & Ops)
Sent: Sunday, February 17, 2019 9:56 AM
To: d...@groovy.incubator.apache.org; dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure

It's a -1 for me.  It took me a lot of work to support @ClosureParams and 
@DelegatesTo in Eclipse.  I'm not looking forward to doing it all over again.

72 hours is not enough time.  Monday is a US holiday, so many will not be at 
work and not checking emails.  You need to send these items out on Tuesdays so 
there is Wed-Fri for people to have a chance to review and ask questions.

From: Daniel.Sun 
Sent: Saturday, February 16, 2019 9:46 AM
To: d...@groovy.incubator.apache.org
Subject: [VOTE] Polish the generics type syntax for closure

Dear development community,

   I completed the GEP for polishing the generics type syntax for closure[1]
just now and happy to start the VOTE thread. The GEP is targeted for Groovy
3.0.0.

The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.

[ ] +1 Polish the generics type syntax for closure
[ ]  0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not polish the generics type syntax for closure because...

Cheers,
Daniel.Sun
[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GROOVY-2D8992=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=1IfyQ4a7ROEdJ4RmHuV1Z3Uc4HNoEnu08hpZVxfRfiQ=

-
Apache Groovy committer
Blog: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=so1mYDnsspDBvtPpTn5v62NLWBDJcsWhxEdJ0UuaRjY=
Twitter: @daniel_sun

--
Sent from: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=MfURAZPAwaAp5xyVTzWnLAHs-lvYB99wDDp7oc8K6zs=TBHY4GkPt16tD6tD5DJ2Mvx4ZBOLRGkRHlIh2tLSou4=

Re: [GEP] Concatenative Method Calls

2019-02-17 Thread Daniel.Sun

Hi Jochen,

 I submitted a JIRA ticket to show the evolving process :-)

https://issues.apache.org/jira/browse/GROOVY-8997


Cheers,
Daniel.Sun



-
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: DGM for first or default

Re: DGM for first or default

Re: DGM for first or default

Re: [editor/tooling support in core groovy]

Re: [VOTE] Polish the generics type syntax for closure

Re: DGM for first or default

Re: [VOTE] Polish the generics type syntax for closure

Re: [VOTE] Polish the generics type syntax for closure

Re: [VOTE] Polish the generics type syntax for closure

Re: [VOTE] Polish the generics type syntax for closure

Re: [GEP] Concatenative Method Calls

11 matches

Site Navigation

Mail list logo

Footer information