I'm +1 on Andrés' plan. Let's have 2_4_X, 2_5_X and `master` for 3.0. Then
it's much easier to do breaking changes on 3.0.
2017-01-18 1:16 GMT+01:00 Daniel Sun :
> Hi Paul,
>
>
>
> OK. I understand others’s fears 😉
>
> Maybe releasing 3.0.0-ea and 2.5.0-beta together suggested by Andr
Hello everyone,
Just yesterday Greg L. Turnquist blogged about an usage pattern of
Spinnaker, Cloud Foundry, and Groovy. See
http://greglturnquist.com/2017/01/reactively-talking-to-cloud-foundry-with-groovy.html
Basically he complains that Groovy can't coerce a Closure to a given SAM
type. In his
This is something that we can improve. We knew it when we implemented SAM
type coercion, and decided to wait until someone complains, to see how
often this use case happens :)
2017-01-18 11:59 GMT+01:00 Andres Almiray :
> Hello everyone,
>
> Just yesterday Greg L. Turnquist blogged about an usage
A word of warning: Solving this according to the spec is a hard problem
(speaking from experience with the Eclipse compiler when supporting Java 8),
especially if you add parameterized types to the equation. To quote the JLS:
"In JSR 335, the greatest complexity lurked in the interaction of impl
I agree with Jesper,
solving all the cases is an uncanny valley.
The JEP 302 [1] has a good introduction on what javac does or not in case of
overloading
(and what currently does not work but is expected to work with java 10).
Also the warning proposed by Jesper exists in javac under the nam
On 18.01.2017 12:33, Remi Forax wrote:
I agree with Jesper,
solving all the cases is an uncanny valley.
The JEP 302 [1] has a good introduction on what javac does or not in
case of overloading
(and what currently does not work but is expected to work with java 10).
Also the warning proposed b
Agreed.
I almost forgot about the special arity case of defining a closure as { /*
do something */ } as it can be called with either 0 or 1 arguments, where
as { -> } accepts no arguments and { x -> } takes exactly one argument.
Would it a a good compromise to support plain typed arguments out of
On 18.01.2017 14:09, Andres Almiray wrote:
Agreed.
I almost forgot about the special arity case of defining a closure as {
/* do something */ } as it can be called with either 0 or 1 arguments,
where as { -> } accepts no arguments and { x -> } takes exactly one
argument.
Would it a a good comp
I meant that { String arg0, int arg1 -> } gives us arity and types, whereas {
arg0, arg1 -> } only gives arity.
Also compare { List arg0, int arg1 -> } vs { List arg0, int arg1 ->
}, the former should be doable whereas the latter will prove difficult.
This is what I meant by plain typed arguments.
ok, I see... we currently do not make use of that information, but
could. Only trouble is that we will be "less expressive" than Java for
these cases.
bye Jochen
On 18.01.2017 14:39, Andres Almiray wrote:
I meant that { String arg0, int arg1 -> } gives us arity and types,
whereas { arg0, arg1
Hello, fellow Apache enthusiast. Thanks for your participation, and
interest in, the projects of the Apache Software Foundation.
I wanted to remind you that the Call For Papers (CFP) for ApacheCon
North America, and Apache: Big Data North America, closes in less than a
month. If you've been puttin
Hi all,
Currently the old parser allows mixing modifiers and annotations,
e.g.
*Current*
@interface Test1 {}
@interface Test2 {}
@Test1 final @Test2 a
*Suggested*
@interface Test1 {}
@interface Test2 {}
@Test1 @Test2 final a
In addition, the order of modifiers is arbitrary too,
Should we check the redundant modifiers? e.g.
*Current*
class A {
private def a // def is redundant. IMHO, I really don't like it...
}
*Suggested*
class A {
private a
}
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and
13 matches
Mail list logo
