Generate list-of-interface getters on Java interfaces - #953
ryanflegel wants to merge 1 commit into
Conversation
| if (useWildcardType) { | ||
| if (typeName is ClassName) { | ||
| if (document.definitions | ||
| if (isFieldTypeAnInterface(node.type)) { |
There was a problem hiding this comment.
Use wildcards for List of interface.
| ) { | ||
| canUseWildcardType = true | ||
| } | ||
| } else if (typeName is ParameterizedTypeName && typeName.rawType().canonicalName() == "java.util.List") { |
There was a problem hiding this comment.
Also use wildcard for List of List (of List...).
This ensure List<List<Interface>> still works and becomes List<? extends List<? extends Interface>>.
It will also unnecessarily do it for concrete types, which should be harmless. e.g., List<List<ConcreteType>> becomes List<? extends List<ConcreteType>>.
| | List<? extends Pet> getFriends(); | ||
| | | ||
| | void setFriends(List<Pet> friends); | ||
| | void setFriends(List<? extends Pet> friends); |
There was a problem hiding this comment.
This demonstrates how interface-setters also have wildcards. This is more flexible for the Java compiler, but may theoretically lead to runtime errors. e.g., if a concrete type only supported a specific subtype of Pet.
Note that this is consistent with the existing generateInterfaces behaviour, but I wanted to point it out.
1 participant
Generate Java getter methods by default for interface fields that are list of interfaces. This is an enhancement to #882, which added getters by default but excluded lists.
I believe lists were probably left out of #882 due to lack of return type compatibility without using wildcard types. i.e.,
List<ConcreteType>does not overrideList<Interface>, but it does overrideList<? extends Interface>.This PR basically implements the latter and re-uses the same wildcard logic that was created for the
generateInterfacesflag. It also introduces wildcards for interfaceListsetters on interfaces, which is consistent with howgenerateInterfacesworks (and because it shares the logic).