About type inference of method return value

classic Classic list List threaded Threaded
21 messages Options
123
Reply | Threaded
Open this post in threaded view
|

About type inference of method return value

Daniel Sun
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
MG
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

MG
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 <[hidden email]>
Datum: 05.09.18 06:49 (GMT+01:00)
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
MG
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

MG
In reply to this post by Daniel Sun
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 <[hidden email]>
Datum: 05.09.18 06:49 (GMT+01:00)
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
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

Cédric Champeau
In reply to this post by Daniel Sun
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

Daniel.Sun
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

Cédric Champeau
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

Daniel.Sun
In reply to this post by MG
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

Daniel.Sun
In reply to this post by Cédric Champeau
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
MG
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

MG
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" <[hidden email]>
Datum: 05.09.18 14:02 (GMT+01:00)
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
MG
Reply | Threaded
Open this post in threaded view
|

Re: About type inference of method return value

MG
In reply to this post by Daniel.Sun
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" <[hidden email]>
Datum: 05.09.18 14:02 (GMT+01:00)
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
123