It would be nice to accept a method as a setter even if it is declared to return an ancestor type. E.g.,
public interface MyInterface {
public int getValue();
public MyInterface setValue(int value);
}
public class MyImplementation implements MyInterface {
private int value;
@Override public int getValue() { return value; }
@Override public MyInterface setValue(int value) {
this.value = value; return this;
}
}
(Putting aside for a moment that in this case we could declare the overridden method with a more restrictive return type. In my particular case the implementation is generated code.)
Podam would fail to consider MyImplementation#setValue(int) to be a setter, because it returns MyInterface rather than MyImplementation. Is there any reason not to allow this case?
As far as I can tell, my only work-around at the moment would be to re-implement all of AbstractClassInfoStrategy#findPojoAttributes in a custom class info strategy, which seems like a lot of unnecessary work. Essentially, I'd like to make the following change in that method:
It would be nice to accept a method as a setter even if it is declared to return an ancestor type. E.g.,
(Putting aside for a moment that in this case we could declare the overridden method with a more restrictive return type. In my particular case the implementation is generated code.)
Podam would fail to consider
MyImplementation#setValue(int)
to be a setter, because it returnsMyInterface
rather thanMyImplementation
. Is there any reason not to allow this case?As far as I can tell, my only work-around at the moment would be to re-implement all of
AbstractClassInfoStrategy#findPojoAttributes
in a custom class info strategy, which seems like a lot of unnecessary work. Essentially, I'd like to make the following change in that method:to