[api-xml-adjuster] constructors could reference generic type parameters. #147
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Constructors had been considered to NOT reference generic type parameters because Java syntax does not allow them. However, its argument types could be java.lang.Class<T> in class-parse output XML (which I guess is because class-parse tries to be as simple-and-stupid as it can be?) and every difficulty is thrown toward api-xml-adjuster. Hence it is corrected here. Note that it was not the first time that generic constructor arguments have been taken care as a valid input (0ec431e).
|
That's quite untrue; the previous commit introduces generics in constructor signature itself. This commit supports use of generic arguments in constructors which is NOT part of genericTypeParameters, which were added in the updated Android reference docs. They are TOTALLY different. |
jonpryor
pushed a commit
to jonpryor/java.interop
that referenced
this pull request
Jun 5, 2017
…rs. (dotnet#147) Constructors had been considered to NOT reference generic type parameters because Java syntax does not allow them. However, its argument types could be java.lang.Class<T> in class-parse output XML (which I guess is because class-parse tries to be as simple-and-stupid as it can be?) and every difficulty is thrown toward api-xml-adjuster. Hence it is corrected here. Note that it was not the first time that generic constructor arguments have been taken care as a valid input (0ec431e).
jonpryor
pushed a commit
that referenced
this pull request
Jun 5, 2017
…rs. (#147) Constructors had been considered to NOT reference generic type parameters because Java syntax does not allow them. However, its argument types could be java.lang.Class<T> in class-parse output XML (which I guess is because class-parse tries to be as simple-and-stupid as it can be?) and every difficulty is thrown toward api-xml-adjuster. Hence it is corrected here. Note that it was not the first time that generic constructor arguments have been taken care as a valid input (0ec431e).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Constructors had been considered to NOT reference generic type parameters
because Java syntax does not allow them. However, its argument types could
be java.lang.Class in class-parse output XML (which I guess is because
class-parse tries to be as simple-and-stupid as it can be?) and every
difficulty is thrown toward api-xml-adjuster. Hence it is corrected here.
Note that it was not the first time that generic constructor arguments
have been taken care as a valid input (0ec431e).