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

Why fields instead of properties? #44

Open
adambajguz opened this issue May 15, 2021 · 3 comments
Open

Why fields instead of properties? #44

adambajguz opened this issue May 15, 2021 · 3 comments

Comments

@adambajguz
Copy link

This issue partially relates to #21: "It's very clear you guys are Java developers. Lowercase properties, reverse-domain namespaces. To a .Net developer, this feels really gross to work with."

Recommendation:

  • Models and API Client should use properties for public members
@mooreds
Copy link
Contributor

mooreds commented May 17, 2021

Thanks for your feedback. We're currently reviewing how we generate our client libraries in order to offer a more native experience, but it's good to hear specifics. Thanks!

@Mike-Logit
Copy link

Mike-Logit commented Aug 9, 2022

I just checked out the source code and thought "oh wow this is ugly. Looks like a Java dev trying out C# for the first time". But as long as it works then good job. I just wish I didn't have to include code calling and using this Java-styled API in my workplace's codebase because it's mixing up 2 very different code styles in the same project/s. It might confuse the other devs.

@voidmain
Copy link
Member

Have you all reviewed the Open API specification? We are likely going to be moving to Open API here soon, so take a look there and let us know what you think:

https://github.com/fusionauth/fusionauth-openapi

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

4 participants