-
Notifications
You must be signed in to change notification settings - Fork 42
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
Simplify the handling of parameterized types #66
Comments
currently, when Class is parameterized, we need to add signature like that:
I have introduce on PR a signature generation. |
ok so now code is ready for review. I do not think it is ready for merge but size of patch need review to know If I go on right direction. I try to not break API which lead to some stuff
basic API is
I was thinking to a system to forward formalType from creator to method but it is not that simple. because some methods needs it and other don't. But Idea was to add it to classCreator and auto add to method if param used it but for that I must be able to go to classCreator from methodCreator if I have param with one letter and match with class one. current implementation split generic part in SignatureUtils.visitType() but I am thinking to merge it to all type just by adding then remove all generics for descriptor but keep it for signature. Advantage no need for extra field (except formalTypes). |
This pull request handles the support of parameterized types when creating methods. Example: ```java public List<String> methodName() { } ``` Where `List<String>` is a parameterized type. In order to do this, we need to amend the `signature` of the method as the descriptor does not support it (it says class not found when trying to declare `Ljava.util.List<Ljava.lang.String;>;`). In order to resolve this, we have added a wrapper type `ParameterizedClass` where we can specify the wrapper type and the param types. Usage: ``` MethodCreator method = creator.getMethodCreator("methodName", new ParameterizedClass(List.class, String.class)); ``` This pull request partially resolves: quarkusio#66 (which is intended to be for classes too) Moreover, these changes are inspired by the changes in quarkusio/quarkus#26074 (that there will be deprecated once gizmo dependency is bumped). I've verified these changes in Quarkus upstream too (reverting the changes of the mentioned Quarkus pull request) and it worked fine.
I think that this issue was resolved in #147. |
Right now, you need to use
signature
passing it a complex string describing how your type is parameterized. It would be nice if that complexity could be hidden away.The text was updated successfully, but these errors were encountered: