You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2018/09/05 04:49:56 UTC
About type inference of method return value
Hi all,
I am going to refine the type inference of method return value, the
methods should match one of the following charactristics:
1) `final`
2) `private`
3) `static`
4) method defined in Script
The above methods will not be overrided and have exact method return
type.
Any thoughts?
P.S. Currently the following code will fail to compile, but it's
obiviously valid.
```
@groovy.transform.CompileStatic
class Test {
static m() {
return 'abc'
}
static a() {
return m().length()
}
static void main(String[] args) {
assert 3 == a()
}
}
```
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About type inference of method return value
Posted by Paul King <pa...@asert.com.au>.
Daniel, I am not 100% sure what you have in mind - the devil is always in
the detail. Can it be written as a normal type checking extension class?
Cheers, Paul.
On Wed, Sep 5, 2018 at 2:50 PM Daniel Sun <re...@hotmail.com> wrote:
> Hi all,
>
> I am going to refine the type inference of method return value, the
> methods should match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4) method defined in Script
>
> The above methods will not be overrided and have exact method return
> type.
>
> Any thoughts?
>
> P.S. Currently the following code will fail to compile, but it's
> obiviously valid.
> ```
> @groovy.transform.CompileStatic
> class Test {
> static m() {
> return 'abc'
> }
>
> static a() {
> return m().length()
> }
>
> static void main(String[] args) {
> assert 3 == a()
> }
> }
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: About type inference of method return value
Posted by mg <mg...@arscreat.com>.
I agree with Daniel here, I also don't see how this could be confusing (?).
Even if the inference mechanism falls back to inferring Object, the user will just get an "cannot call dadadam on Object" or such compile error - which should immediately leave to the conclusion that the type needs to be given explicitely in this case...
Does anyone have an example that shows such a malign/confusing type deduction case ?
-------- Ursprüngliche Nachricht --------Von: "Daniel.Sun" <su...@apache.org> Datum: 05.09.18 14:02 (GMT+01:00) An: dev@groovy.incubator.apache.org Betreff: Re: About type inference of method return value
I just propose the smarter type inference for methods, which was in my TODO
list.
> We explicitly chose not to be too smart here, because it can be confusing
> to users.
OK. Recently I am developing a project based on Groovy. Writing code with
"dynamic" mind and compile code in "static" way. So I don't care why STC
passes but just care why STC doesn't work and try to fix compilation errors,
some of which impress me that Groovy is not smart enough.
So I don't understand why smarter type inference will confuse users.
Cheers,
Daniel.Sun
Cheers,
Daniel.Sun
-----
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: About type inference of method return value
Posted by "Daniel.Sun" <su...@apache.org>.
I just propose the smarter type inference for methods, which was in my TODO
list.
> We explicitly chose not to be too smart here, because it can be confusing
> to users.
OK. Recently I am developing a project based on Groovy. Writing code with
"dynamic" mind and compile code in "static" way. So I don't care why STC
passes but just care why STC doesn't work and try to fix compilation errors,
some of which impress me that Groovy is not smart enough.
So I don't understand why smarter type inference will confuse users.
Cheers,
Daniel.Sun
Cheers,
Daniel.Sun
-----
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: About type inference of method return value
Posted by Cédric Champeau <ce...@gmail.com>.
Sorry I don't understand what you are saying. What I'm saying is that we
already had such an implementation, and we decided to _remove_ it. Are you
saying that you have a branch that reintroduces it, or that it's already on
master?
I disagree with the statement that the "users require smarter type
inference". Type inference is cool, but it's also hard to predict.
Sometimes you just don't understand why the compiler inferred something or
not. We explicitly chose not to be too smart here, because it can be
confusing to users.
Le mer. 5 sept. 2018 à 13:36, Daniel.Sun <su...@apache.org> a écrit :
> Hi Cédric,
>
> > Basically, it's not easy to realize that when you have a non final
> methods, subclasses can override the method to return a different type.
>
> As I proposed, the methods with smarter return type inference should
> match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4) method defined in Script
>
> So these methods will not be overrided and the return type will be
> exact.
>
> I will leave the implementation as it is util most of groovy users
> require the smarter type inference ;-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -----
> 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: About type inference of method return value
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Cédric,
> Basically, it's not easy to realize that when you have a non final
methods, subclasses can override the method to return a different type.
As I proposed, the methods with smarter return type inference should
match one of the following charactristics:
1) `final`
2) `private`
3) `static`
4) method defined in Script
So these methods will not be overrided and the return type will be
exact.
I will leave the implementation as it is util most of groovy users
require the smarter type inference ;-)
Cheers,
Daniel.Sun
-----
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: About type inference of method return value
Posted by Cédric Champeau <ce...@gmail.com>.
Hi Daniel,
We discussed this when we implemented static compilation in the past. There
were 2 different relates cases discussed:
- smarter type inference for final fields
- smarter type inference for final methods
and decided not to implement them, so that it's not confusing for users
when the compiler can infer a type in one case and not the other. We can
revisit the decision, just want to give more context. Basically, it's not
easy to realize that when you have a non final methods, subclasses can
override the method to return a different type.
Le mer. 5 sept. 2018 à 06:50, Daniel Sun <re...@hotmail.com> a écrit :
> Hi all,
>
> I am going to refine the type inference of method return value, the
> methods should match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4) method defined in Script
>
> The above methods will not be overrided and have exact method return
> type.
>
> Any thoughts?
>
> P.S. Currently the following code will fail to compile, but it's
> obiviously valid.
> ```
> @groovy.transform.CompileStatic
> class Test {
> static m() {
> return 'abc'
> }
>
> static a() {
> return m().length()
> }
>
> static void main(String[] args) {
> assert 3 == a()
> }
> }
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: About type inference of method return value
Posted by "Daniel.Sun" <su...@apache.org>.
This is another smarter type inference for `final`, which should work too if
my proposal is supported by most of groovy users.
Cheers,
Daniel.Sun
-----
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: About type inference of method return value
Posted by mg <mg...@arscreat.com>.
Hi Daniel,
would the following case work:
class Goo { @Lazy static final Goo instance = new Goo(...) static getGOO() { instance } // return type deduced to be Goo ?}
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: Daniel Sun <re...@hotmail.com> Datum: 05.09.18 06:49 (GMT+01:00) An: dev@groovy.incubator.apache.org Betreff: About type inference of method return value
Hi all,
I am going to refine the type inference of method return value, the
methods should match one of the following charactristics:
1) `final`
2) `private`
3) `static`
4) method defined in Script
The above methods will not be overrided and have exact method return
type.
Any thoughts?
P.S. Currently the following code will fail to compile, but it's
obiviously valid.
```
@groovy.transform.CompileStatic
class Test {
static m() {
return 'abc'
}
static a() {
return m().length()
}
static void main(String[] args) {
assert 3 == a()
}
}
```
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html