-
Notifications
You must be signed in to change notification settings - Fork 55
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
fix: Fix BetaApi
annotaiton usage for REST transport and clean BetaApi
for default stubs in all transports
#987
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding correctly, this part is saying that we don't generate
BetaApi
annotation for the first getter, but generate it from the second one. I understand we may only have GRPC and HttpJson for now, but it's not easy to read and looks like a hack to me. Can we add the annotation based on something more concrete? Like override this method or part of the method in the subclass?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an already present paradigm in the TransportContext - it has a bunch of transport-specific lists, where first element in transport is a primary one, all others are secondary. For now there are yes, just two transports, but this is a current architecture decision which I don't think are to be changed in scope of this PR. Overriding method is a valid thing but in that case TransportContext should not exist at all in that case (the difference between transports should be done via overriding methods in each transport). I never liked
TransportContext
as a design decision (and originally it all was done via overriding methods), but i is the current design.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked how TransportContext is used and I see where you are coming from. Without changing the design, I think there is still something we can do to improve it:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment.
For the hardcoded method names - changing that is beyond the scope of this PR. There are way too many inline string constants here and there, so changing a few here won't change much. Also to the best of my knowledge, having inline constants is idiomatic an preferred to having separate explicit constants if they remain private and are not reused. I think about it this way: we are generating code here, that code has lots of names, having htem as a bunch of constant scattered all over the place does not seem helping but instead making things harder because it adds another level of indirection when inspecting code. Another example: if "printf" style is used for generation then all of those method are also a bunch of strings. It templates is used, then those method names are again just string in templates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should just used the string literal if it is not reused, I was suggesting more like extracting all the method names and centralize them, then reuse them whenever we need it, and this is a good place for us to reuse it, instead of relying on the order of method names in the list. However, I think this refactoring effort can also be done in a separate PR, it does not have to block this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it is a totally valid point and would be probably a good architectural decision, but looks like it would make sense only as a separate global refactoring (which will create that centralized naming repoisitory). Before that "repository" is created, we can't do it properly in scope of this PR.