ResolvedType.getAllTypes() returns parent, this, and interfaces #56
Conversation
|
@krzysiekbielicki Thank you for contributing this! I hope to check out PR soon but have a few things queued up -- but I wanted to add a note to say that I saw this and will try to get to it ASAP. @ljnelson WDYT? |
cowtowncoder
added
hacktoberfest
|
I'll let you folks figure it out. I did my own thing over here. I opted to always include the full set of types, i.e. not just the parent but the grandparent and so on. See: https://microbean.github.io/microbean-type/apidocs/org/microbean/type/Types.html#toTypes(java.lang.reflect.Type) |
|
Ah, right. So as implemented the method does not include types recursively, but only immediate parent. So yes, that should be added; at least I don't see as much value in something that only includes immediate super types. |
| * | ||
| * @return List of parent, current and interfaces of this type containing at least current type | ||
| */ | ||
| public List<ResolvedType> getAllTypes() { |
There was a problem hiding this comment.
Needs to resolve super types recursively, as methods called will only include immediate super class, interfaces implemented; but not super types of those types.
I think name should be getAllSuperTypes(); I also think that list should NOT include type itself (so that name makes sense in that context).
It might make sense to refactor this so that were two variants:
getAllSuperTypes()to work as describedaddAllSuperTypes(Collection<ResolvedType>)that would add types into given set
... and come to think of this, I realized that List does not quite make sense here, for two reasons:
- There is no well-defined ordering for inclusion; for this reason, we could just use
Collection. But further, - Since it will be necessary to avoid duplicate interfaces (there are cases where things like
java.io.Serializableare implemented via multiple super-interfaces).
So most likely return type really should be Set. This does open up some further questions (should differently parameterized super-types -- say, Comparable<X> vs Comparable<Y>; or, some cases, "raw" variant -- be included once or multiple times), but for now simple equality could work (which would lead to double inclusion for varying type parameters).
Finally, there may be a problem with recusive types (most common being Enum...), so a test for that might be needed. But I can take care of that.
Convenience method for the full set of types for a type (fixes #50)