groovy

@Override should be allowed (and verified) on properties that implement an interface

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Compiler
  • Labels:
    None
  • Number of attachments :
    0

Description

I would like @Override to be allowed (and verified) on fields that implement an interface.

For instance, this is valid Groovy code: 

interface Parent {
    String getSetting()
}
class Child implements Parent {
    final String setting ='my setting'
}

I'd like to add the @Override to the field and have the compiler verify that it does override the getter in the parent. It should work on boolean getters too, I suppose.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GRECLIPSE-1428 Groovy editor does not respect @Override

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Bug - A problem which impairs or prevents the functions of the product. GROOVY-5413 groovyc should emit errors when @Override is not respected

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. GRECLIPSE-1454 no Eclipse compile error for @Override on methods with signatures that don't match that of the parent class

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Roshan Dawrani added a comment -

Isn't @Override defined by Java and allowed only on methods?

Show
Roshan Dawrani added a comment - Isn't @Override defined by Java and allowed only on methods?
Hide
Permalink
Paul King added a comment -

Hamlet, is it correct that you are really wanting this only on properties? I.e. it is on methods as per Java but allowing the property short-hand to specify the methods?

Show
Paul King added a comment - Hamlet, is it correct that you are really wanting this only on properties? I.e. it is on methods as per Java but allowing the property short-hand to specify the methods?
Hide
Permalink
Hamlet D'Arcy added a comment -

@Override is defined by Java, but Groovy could always loosen that restriction.

I do want it on properties. If "Object getFoo()" is generated, and the object implements an interface where that method is defined, then I'd like to add the @Override annotation. Same goes for "void setFoo(Object)"

Are there other uses cases you had in mind?

Show
Hamlet D'Arcy added a comment - @Override is defined by Java, but Groovy could always loosen that restriction. I do want it on properties. If "Object getFoo()" is generated, and the object implements an interface where that method is defined, then I'd like to add the @Override annotation. Same goes for "void setFoo(Object)" Are there other uses cases you had in mind?
Hide
Permalink
Paul King added a comment -

Well, for interfaces, the only fields are constants so I don't think it makes sense to use @Override with them. But for one class inheriting from another case, you could check that the super class also had a field definition if you had @Override on a field in the child class.

Show
Paul King added a comment - Well, for interfaces, the only fields are constants so I don't think it makes sense to use @Override with them. But for one class inheriting from another case, you could check that the super class also had a field definition if you had @Override on a field in the child class.
Hide
Permalink
Roshan Dawrani added a comment -

>> @Override is defined by Java, but Groovy could always loosen that restriction.

Loosening the restriction just from the Groovy compiler point of view was not my concern. We control it from text to bytecode, so allowing it on properties and shifting the annotations to getters/setters before annotations are validated is a small trick.

My concern was how such loosening of restrictions will play out with IDEs. They spend a lot of effort on giving early feedback and it may come in the way unless they also come at par with Groovy compiler.

Show
Roshan Dawrani added a comment - >> @Override is defined by Java, but Groovy could always loosen that restriction. Loosening the restriction just from the Groovy compiler point of view was not my concern. We control it from text to bytecode, so allowing it on properties and shifting the annotations to getters/setters before annotations are validated is a small trick. My concern was how such loosening of restrictions will play out with IDEs. They spend a lot of effort on giving early feedback and it may come in the way unless they also come at par with Groovy compiler.
Hide
Permalink
Paul King added a comment -

change title s/fields/properties/ as I believe that is what is intended.

Show
Paul King added a comment - change title s/fields/properties/ as I believe that is what is intended.
Hide
Permalink
Paul King added a comment -

So my understanding of the requirement is that if you write (using the example above):

...
class Child implements Parent {
    @Override
    final String setting ='my setting'
}

It should end up being equivalent to:

...
class Child implements Parent {
    @Override
    String getSetting() {
        'my setting'
    }
}

Give or take using a backing field etc. which I will ignore here.

Show
Paul King added a comment - So my understanding of the requirement is that if you write (using the example above): ... class Child implements Parent { @Override final String setting ='my setting' } It should end up being equivalent to: ... class Child implements Parent { @Override String getSetting() { 'my setting' } } Give or take using a backing field etc. which I will ignore here.

People

  • Assignee:
    Unassigned
    Reporter:
    Hamlet D'Arcy
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: