-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[csharp][netcore-httpclient] Refactor of constructors #9145
Conversation
Updated samples Fixed a bug of previous commit Refactor on constructors
👍 Thanks for opening this issue! The team will review the labels and make any necessary changes. |
Minor suggestions: better indentation in the documentation comments and use 4-space instead of tabs |
Mark the constructors without HttpClient as obsolete already. I think we all agree that they should not be used except as a compatibility fallback. Aside from that it looks good |
Ok, give me a feedback on the message if it fits, i will change it as you prefer |
I would change the Message to: Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details Aside from that LGTM |
I will change the message to "Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details." asap. |
If you have time to review it and merge it, it's all done. |
LGTM |
I have a different opinion on this. Will submit a PR with a use case to start the discussion later (before 5.1.1 release) Will merge this one to keep the ball rolling. |
I ran out of time to submit a PR. Here is what I would suggest: Do NOT mark constructors (e.g. The reason is to cater simple use cases. Consider that the situation in which I want to make a simply call (e.g. GetPetById) to the API server and get something back. All I need is a simple call to get some objects (e.g. Pet) from the server and I only need to make the call once. Performance is not a concern/requirement in the use case. The goal is to make the auto-generated C# SDK easy-to-use. What do you guys think? |
If you want to go in the milestone without the obsolete marker and postpone the brainstorm further I will remove the attributes in a few hour. They were put after the discussion on slack/here to emprove the usate, I think in a .net core application you will embrace the bootstrap and DI so the httpClient is the proper way to go. Said that, for sure in a smaller project the easier constructor Is preferred. So maybe an obsolete attribute is too much, it is enough to have the new constructors and the readme. Let me know if i can help you to reach the needs in time. |
Yes, please file a PR hwen you've time. |
Done in PR #9373. |
It tries to reduce the number of constructors introduced in previous PR.
Related to: #9060, #9085
Refactor on constructors
In the previous PM I created too much constructors.
This is an emprovement to reduce them:
With this PM we have in ApliClient:
(point 1-2 marked as obsolete)
and in ApiClass:
(point 1-3 marked as obsolete)
Obsolete constructors
Marked constructors without the explicit HttpClient parameter as obsolete.
Spaces and indentations
Unfortunatly I had a different setup for spaces and indentations on my IDE and I did not see it on my local versioning tool.
So the changes have some spaces because I fixed my previous PM, moving some tabs to 4 spaces.
They are a few lines not so much, but this is why you see some noise in the diffs, its a fix to keep and I will avoid it at all in the future.
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.For Windows users, please run the script in Git BASH.
master
,5.1.x
,6.0.x
@mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03)