Skip to content
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

Adding Dictionarry<sting, sting> to Respone #26

Closed
MaximilianAst opened this issue May 21, 2018 · 4 comments
Closed

Adding Dictionarry<sting, sting> to Respone #26

MaximilianAst opened this issue May 21, 2018 · 4 comments

Comments

@MaximilianAst
Copy link
Contributor

MaximilianAst commented May 21, 2018

Hay Nikeee what do you think about adding a Dictionarry<sting, sting> (or IReadOnlyList<KeyValuePair<string, string>>) to the respone class for all respone-parameters that couln't be deserialized?

@nikeee
Copy link
Owner

nikeee commented May 21, 2018

Do you have a specific use-case in mind? I'd prefer having them as fields, if it is known that the response will have them.

@MaximilianAst
Copy link
Contributor Author

MaximilianAst commented May 21, 2018

For properties, we didn't considered yet, but are awailabe through the API. To prevent s.th. lilke in #25 (at least parcially)

@nikeee
Copy link
Owner

nikeee commented May 21, 2018

If these properties are implemened in the following release, the existing code would break if they update the dependency (or if it's a patch/minor release, if they re-install the dependeny).

I'd just prefer to implement these things correctly in the first place.

@nikeee
Copy link
Owner

nikeee commented May 21, 2018

I opened #28 that covers this concept in a similar way: How about including not only the unprocessed, but all fields? This would eliminate compability issues.
We can discuss further ideas in #28.

@nikeee nikeee closed this as completed May 21, 2018
@nikeee nikeee mentioned this issue May 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants