-
Notifications
You must be signed in to change notification settings - Fork 28
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
feature/serialization helpers #767
Conversation
Signed-off-by: Vincent Biret <[email protected]>
Kudos, SonarCloud Quality Gate passed! |
Please retry analysis of this Pull-Request directly on SonarCloud. |
Kudos, SonarCloud Quality Gate passed! |
Please retry analysis of this Pull-Request directly on SonarCloud. |
Kudos, SonarCloud Quality Gate passed! |
Kudos, SonarCloud Quality Gate passed! |
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.
@baywet , I'm wondering if the serializeAsString methods should be differentiated similar as to how you differentiate the deserialize methods. Perhaps serializeCollectionAsString or serializeCollectionAsStream? Otherwise looks good!
@ramsessanchez yeah I was wondering that too, we don't technically need to do it as the parameters types are different. It's a matter of consistency vs convenience. I believe the current situation feels familiar to the ecosystem (i.e. Java devs are used to overload with different parameters types) |
related microsoft/kiota#3406