[go-experimental] Preserve capitalized acronyms in structure names#5006
Conversation
|
I think #4900 aims to fix similar issue. |
|
@wing328 yeah, it's similar. What's different is that my PR doesn't touch the existing stable Go client (because this change would break backwards compatibility) and I think my PR is much simpler and it addresses the root cause of this issue (the solution in #4900 feels more like a workaround). Do note that this issue isn't present in e.g. Java client generator (or other generators that I've seen), so I think it doesn't need a solution on the level of |
|
I agree that #4900 seems more like a workaround. It also seems like it will break literally every client with something that looks like an initialism or acronym when the user may not have intended this. For projects with static analysis rules, it may trigger warnings about identifiers not matching casing rules. For example, if you take any of the Java/jvm clients and push them to sonarcloud, you'll get a ton of warnings. I much prefer the approach in this PR, since rules around language supported capitalization should be left to the language/framework and not forced globally. |
3 participants
Currently an openapi model called e.g.
EntityURLwould have a structure generated with nameEntityUrl. I think this is both against the intention of the spec author and it is also against Go naming recommendations. This PR fixes that to preserve the capitalized acronyms.PR checklist
./bin/(or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run./bin/{LANG}-petstore.sh,./bin/openapi3/{LANG}-petstore.shif updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).master,4.3.x,5.0.x. Default:master.@antihax (2017/11) @bvwells (2017/12) @grokify (2018/07) @kemokemo (2018/09) @bkabrda (2019/07)