-
-
Notifications
You must be signed in to change notification settings - Fork 44
Correct approach to compare ResolvedType
with a raw Class<?>
?
#72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What you include sounds like the way to do it, in general case (and yes, for special case of non-generic type, just checking "erased type" would be the thing to do). I'd be open to adding convenience method if there's an obvious API addition to do (that is, generally useful method to add). |
Thanks for the reply. I'll continue with my project project and learn more about the best approach; and consider what convenience function would be useful. Note that I updated the code in the question, because after running my code I realized that |
Ah. Yes. I should have read your sample more carefully. Yes, |
Uh oh!
There was an error while loading. Please reload this page.
What's the appropriate way to see if a
ResolvedType
represents a simple class that I know about?Let's say I pass a
new GenericType<String>{}
to a method, and I just want to see if the generic parameter isString
. I think (I haven't tried it yet) I would do this (code not optimized, for illustration):How would I then see if
resolvedType
indicates a simpleString
? I'm guessing I could do this:But that seems sort of awkward. Is there a better way?
(Note that the
resolvedType.getTypeParameters.isEmpty()
check is arguably not necessary here, asString
has no generic parameters, but I'm looking for a general approach.)Or should I be going in the other direction, resolving
String.class
and then comparing the resolved types?I don't know how much overhead the extra resolution of
String.class
adds, though.This may be related to #31.
The text was updated successfully, but these errors were encountered: