Re: About the "implies" operator(GROOVY-2576)

Hi Jochen, Thanks for your analysis in detail :) => is a very expressive operator. if we could implement it as +(corresponding to plus method) does and apply different business logic when necessary, it would be much more useful. And the default implementation of "implies" method c

Re: About the "implies" operator(GROOVY-2576)

On 25.01.2017 17:50, Daniel Sun wrote: Hi all, The "implies" operator "=>" was suggested many years ago, here is the replated JIRA issue( GROOVY-2576 ) . Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad) BTW, re

Re: About the "implies" operator(GROOVY-2576)

+1 On Wed, Jan 25, 2017 at 9:28 AM, Mario Garcia wrote: > +1 if follows the convention mentioned by Andres > > On 25 Jan 2017 17:58, "Andres Almiray" wrote: >> >> Is the "implies" method supposed to work with Groovy Truth or with >> booleans only? >> If the former then this would pose a problem

Re: About the "implies" operator(GROOVY-2576)

+1 if follows the convention mentioned by Andres On 25 Jan 2017 17:58, "Andres Almiray" wrote: > Is the "implies" method supposed to work with Groovy Truth or with > booleans only? > If the former then this would pose a problem as anyone that has defined an > "X implies(Y)" method would have acc

Re: Traits and protected properties

Russel is looking to build GPars V2.0 as JDK8+ later this year, so timing for Groovy 3 would be nice. Sent from my iPad > On 25 Jan 2017, at 16:43, Cédric Champeau wrote: > > That's only ok once we generate Java 8+ class files only. Otherwise, you > create a language that, syntactically, sup

Re: About the "implies" operator(GROOVY-2576)

Is the "implies" method supposed to work with Groovy Truth or with booleans only? If the former then this would pose a problem as anyone that has defined an "X implies(Y)" method would have access to => If the latter then I guess that may not be a proplem. Assuming "X implies(Y)" would be the conv

Re: About the "implies" operator(GROOVY-2576)

+1 yes, especially if it's overloadable as per the other operators On Wed, Jan 25, 2017 at 11:50 AM, Daniel Sun wrote: > Hi all, > > The "implies" operator "=>" was suggested many years ago, here is the > replated JIRA issue( GROOVY-2576 >

About the "implies" operator(GROOVY-2576)

Hi all, The "implies" operator "=>" was suggested many years ago, here is the replated JIRA issue( GROOVY-2576 ) . Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad) BTW, recently I have been going through the issues

Re: Traits and protected properties

Yes, that's why Groovy 3 really seems to be the "blow up everything" version to me 2017-01-25 17:00 GMT+01:00 Daniel Sun : > Hi Cédric, > > As far as I remember, Groovy 3+ will require Java 8. So maybe we could > upgrade the default version of class file to Java 8+ in Groovy 3+ releases? > >

Re: Traits and protected properties

Hi Cédric, As far as I remember, Groovy 3+ will require Java 8. So maybe we could upgrade the default version of class file to Java 8+ in Groovy 3+ releases? Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5

Re: Traits and protected properties

That's only ok once we generate Java 8+ class files only. Otherwise, you create a language that, syntactically, supports static methods on interfaces, but cannot compile them for older JDKs. Since we generate JDK 5+ class formats, we cannot do this without upgrading our requirements, or adding "con

Re: Traits and protected properties

Hi Cédric, > oh and that's written in the docs Groovy's documentation is so detail... it's hard for me to believe ;) BTW, Java 8 supports static methods and default methods in the interfaces, how about refining the implementation of traits based on the enhanced interfaces? then traits can have i

Re: Traits and protected properties

oh and that's written in the docs: http://docs.groovy-lang.org/2.4.0/html/documentation/core-traits.html#_static_methods_properties_and_fields But who reads the f* manual? :) 2017-01-25 14:54 GMT+01:00 Cédric Champeau : > Static methods are *copied* to the weaved class. They do not belong to the

Re: Traits and protected properties

Static methods are *copied* to the weaved class. They do not belong to the trait itself. 2017-01-25 14:53 GMT+01:00 Daniel Sun : > Hi Graeme, > > Here is my test code, which fails: > > trait A { > public static String m() { return '123' } > } > > A.m() > > error messages: > > groovy.lang

Re: Traits and protected properties

Hi Graeme, Here is my test code, which fails: trait A { public static String m() { return '123' } } A.m() error messages: groovy.lang.MissingMethodException: No signature of method: static A.m() is applicable for argument types: () values: [] Possible solutions: is(java.lang.Object),

Re: Traits and protected properties

Maybe I'm missing something, but traits do support static methods. We use them extensively in GORM On Wed, Jan 25, 2017 at 1:47 PM, Daniel Sun wrote: > OK. I see. Thanks :) > > BTW, the interface with default methods is based on Traits, I found Traits > does not support static methods too... So m

Re: Traits and protected properties

OK. I see. Thanks :) BTW, the interface with default methods is based on Traits, I found Traits does not support static methods too... So maybe we should generate bytecode for default methods and static methods of interface as Java 8 do. Cheers, Daniel.Sun -- View this message in context: htt

Re: Traits and protected properties

That's because of the way traits are wired into bytecode. They "look like" belonging to the same hierarchy, but we're delegating to static methods. So we cannot enforce the protected semantics. 2017-01-25 13:24 GMT+01:00 Daniel Sun : > Hi Cédric, > > > having a protected property just cannot wo

Re: release process

Hi Jesper, > I recognise that the Antlr4 parser AST building looks really neat in Java > 8, but easthetics aside That's why I choose Java 8 to rewrite the parser :) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738020.html Se

Re: Traits and protected properties

Hi Cédric, > having a protected property just cannot work Could you tell me why trait does not support protected property? Thanks, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738019.html Sent from the Groovy Dev m

Re: Traits and protected properties

I don't think it's breaking change, since having a protected property just cannot work :) 2017-01-25 13:12 GMT+01:00 Andres Almiray : > +1. > > This being a potential breaking change should IMHO be scheduled for 3.0-ea. > > --- > Java Champion; Groovy Enthu

Re: Traits and protected properties

Any additional constraints that should be checked regarding static members? I'd assume "public static final" fields are injected as constants. What about static methods? I must confess I've never used Groovy traits so far. Cheers, Andres --- Java Champion

Re: Traits and protected properties

+1. This being a potential breaking change should IMHO be scheduled for 3.0-ea. --- 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

Re: Traits and protected properties

+1, this is an oversight from my side, protected properties should be prohibited too. 2017-01-25 12:56 GMT+01:00 Paul King : > Hi, for traits we explicitly prohibit protected (and package private) > methods - see the doco for some details. For properties however, we > never check (in 2.4.7 and ea

Traits and protected properties

Hi, for traits we explicitly prohibit protected (and package private) methods - see the doco for some details. For properties however, we never check (in 2.4.7 and earlier) for that case (protected) and in fact include the property in the trait as if it was private. I was thinking of adding an extr