You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2017/01/25 11:56:31 UTC

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 extra check to prohibit protected properties
since I don't think we can give any special meaning beyond private (or
public) and it's only confusing to let that case through. Any other
opinions?

Cheers, Paul.

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 <re...@hotmail.com>:

> 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-tp5738002p5738031.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Traits and protected properties

Posted by Daniel Sun <re...@hotmail.com>.
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-tp5738002p5738031.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

Posted by Jim Northrop <ja...@googlemail.com>.
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 <ce...@gmail.com> wrote:
> 
> 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 "conditional features".
> 
> 2017-01-25 16:37 GMT+01:00 Daniel Sun <re...@hotmail.com>:
>> 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 its own static methods and method
>> implementation(based on the default method).
>> 
>> Cheers,
>> Daniel.Sun
>> 
>> 
>> 
>> --
>> View this message in context: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738028.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
> 

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 "conditional features".

2017-01-25 16:37 GMT+01:00 Daniel Sun <re...@hotmail.com>:

> 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 its own static methods and method
> implementation(based on the default method).
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Traits-and-protected-properties-tp5738002p5738028.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Traits and protected properties

Posted by Daniel Sun <re...@hotmail.com>.
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 its own static methods and method
implementation(based on the default method).

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738028.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 <ce...@gmail.com>:

> 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 <re...@hotmail.com>:
>
>> 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), any(), dump(),
>> any(groovy.lang.Closure), use([Ljava.lang.Object;),
>> tap(groovy.lang.Closure)
>>
>>         at ConsoleScript7.run(ConsoleScript7:5)
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/Traits-and-protected-properties-tp5738002p5738025.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>
>

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 <re...@hotmail.com>:

> 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), any(), dump(),
> any(groovy.lang.Closure), use([Ljava.lang.Object;),
> tap(groovy.lang.Closure)
>
>         at ConsoleScript7.run(ConsoleScript7:5)
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Traits-and-protected-properties-tp5738002p5738025.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: Traits and protected properties

Posted by Daniel Sun <re...@hotmail.com>.
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), any(), dump(),
any(groovy.lang.Closure), use([Ljava.lang.Object;), tap(groovy.lang.Closure)

	at ConsoleScript7.run(ConsoleScript7:5)



--
View this message in context: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738025.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

Posted by Graeme Rocher <gr...@gmail.com>.
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 <re...@hotmail.com> 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 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: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738022.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



-- 
Graeme Rocher

Re: Traits and protected properties

Posted by Daniel Sun <re...@hotmail.com>.
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: http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738022.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 <re...@hotmail.com>:

> 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 mailing list archive at Nabble.com.
>

Re: Traits and protected properties

Posted by Daniel Sun <re...@hotmail.com>.
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 mailing list archive at Nabble.com.

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
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 <aa...@gmail.com>:

> +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 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, Jan 25, 2017 at 12:56 PM, Paul King <pa...@asert.com.au> wrote:
>
>> 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 extra check to prohibit protected properties
>> since I don't think we can give any special meaning beyond private (or
>> public) and it's only confusing to let that case through. Any other
>> opinions?
>>
>> Cheers, Paul.
>>
>
>

Re: Traits and protected properties

Posted by Andres Almiray <aa...@gmail.com>.
+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 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, Jan 25, 2017 at 12:56 PM, Paul King <pa...@asert.com.au> wrote:

> 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 extra check to prohibit protected properties
> since I don't think we can give any special meaning beyond private (or
> public) and it's only confusing to let that case through. Any other
> opinions?
>
> Cheers, Paul.
>

Re: Traits and protected properties

Posted by Andres Almiray <aa...@gmail.com>.
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; 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, Jan 25, 2017 at 12:56 PM, Paul King <pa...@asert.com.au> wrote:

> 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 extra check to prohibit protected properties
> since I don't think we can give any special meaning beyond private (or
> public) and it's only confusing to let that case through. Any other
> opinions?
>
> Cheers, Paul.
>

Re: Traits and protected properties

Posted by Cédric Champeau <ce...@gmail.com>.
+1, this is an oversight from my side, protected properties should be
prohibited too.

2017-01-25 12:56 GMT+01:00 Paul King <pa...@asert.com.au>:

> 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 extra check to prohibit protected properties
> since I don't think we can give any special meaning beyond private (or
> public) and it's only confusing to let that case through. Any other
> opinions?
>
> Cheers, Paul.
>