[go-experimental] Add model constructors to initialize non-container vars with defaults#5175
Conversation
a7d7efc to
9df0d30
Compare
There was a problem hiding this comment.
can you add a docstring?
There was a problem hiding this comment.
Any reason not to require the required Params in the input?
There was a problem hiding this comment.
@jirikuncar thanks for pointing out the docs I'll fix that.
@platinummonkey I think the problem here is that it's not straightforward what to do with required params that have defaults set. Should these be required arguments for the constructor or not? I think that this uncertainty is why generated constructors in other similar languages don't have required params either. I'd like to stay consistent here, so that's why I chose this approach.
There was a problem hiding this comment.
I pushed a new commit that adds both the docstring and also documentation in model_doc.
There was a problem hiding this comment.
New<ClassName>(args....) vs NewDefault<ClassName>() maybe is more clear?
There was a problem hiding this comment.
@platinummonkey I just realized one more reason that is problematic with the required properties:
Imagine that you have required properties A and B and code generated for that: NewFoo(A, B). Now a change happens that makes B optional. You regenerate the code and suddenly you get NewFoo(A) - so that's backwards incompatible. But the change you did in API is backwards compatible, so this breaks the promise of not breaking API of the generated client when a non-breaking API change happens.
There was a problem hiding this comment.
I'm not actually sure that's a problem, if you need to introduce a var, this this method signature is also changed. The alternative is to list all variables, and if one becomes non-optional though or a new one is added then still the signature is changed. Seem moot given go's syntax.
There was a problem hiding this comment.
The signature of this method will never change, as it never accepts any arguments. But I think I'm starting to like the solution proposed in your previous comment with New(required, args, ...) and NewWithDefaults(). Assuming we clearly document that the contract of the former will always change when the set of required arguments changes, it should be ok. I'll work on this.
samples/client/petstore/go-experimental/go-petstore/model_animal.go
Outdated
Show resolved
Hide resolved
d0da1f1 to
d2d9dd4
Compare
|
For anyone reviewing, please hold merging this until #5150 is merged. Thanks! |
…vars with defaults
…ate constructors right under all circumstances
8661844 to
358648b
Compare
|
Ok, rebased and ready to merge now. |
|
FWIW, bitrise failed because of an unrelated error (at least that's how I understand it): |
…vars with defaults (OpenAPITools#5175) * [go-experimental] Add model constructors to initialize non-container vars with defaults * Add docstring and extend model_doc to include the constructor * Make variable names in constructor follow Go naming guidelines * Provide 2 different constructurs as suggested + couple fixes to generate constructors right under all circumstances * Fix defaults for enums * Properly escape vars that have reserved names
This PR adds a constructor to all models that initializes non-container vars with proper defaults. It might also be possible to do container vars in the future, but that is pretty tricky (and also not as widely used to my knowledge).
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)