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

[charp-netcore] Constructor Improvements #11502

Merged
merged 28 commits into from
Feb 15, 2022

Conversation

devhl-labs
Copy link
Contributor

@devhl-labs devhl-labs commented Feb 3, 2022

Description

The goal here is to improve model and api constructors. For models, the existing code gives all parameters a default value whether the parameter is nullable or not. This enables a class to be constructed in a bad state, where parameters that should never be null are. This PR will fix that. I am trying to do this in a way that will only effect the generic host library.

Removed sortParamsByRequiredFlag option from AbstractCSharp

All C# libraries should be sorting signature arguments so those with default values are last. I removed the CLI switch but enabled the option (the default was true anyway). I also enabled setSortModelPropertiesByRequiredFlag but only for GenericHost. It seems like a bug that it wasn't enabled before, but due to the constructor allowing all properties to be null, this was okay.

Added Lambdas RequiredParameterLambda and OptionalParameterLambda

The required lambda will strip a ? from the text if present. The optional lambda will append a ? if it is not present. I will explain below a bit more about why we need this.

Sorting parameters

We were not sorting models before at all. This was not an issue because all parameters were given default values.

Modified Constructors

Modified model constructors to not provide default values for non-nullable properties. This was rather difficult because there are two properties of note: required and isNullable. Unless I'm misunderstanding something, it seems that all non-required properties should be nullable. So when we decide if a property is nullable, we must look at both properties and also deal with specs that give us non-required and non-nullable properties, which doesn't make sense. That is where the new lambdas help us. If we just add the ? like string{{nrt?}} then we might end up with string??. I'll try to explain the new model constructor but it might be fruitless here since it is so long.

public {{classname}}({{#readWriteVars}}
#nullable #required = nullable, use lambda.optional
{{#isNullable}}{{#required}}{{#lambda.optional}}{{{datatypeWithEnum}}}{{/lambda.optional}}{{/required}}{{/isNullable}}
^nullable ^required = nullable, use lambda.optional
{{^isNullable}}{{^required}}{{#lambda.optional}}{{{datatypeWithEnum}}}{{/lambda.optional}}{{/required}}{{/isNullable}}
^nullable #required = required
{{^isNullable}}{{#required}}{{{datatypeWithEnum}}}{{/required}}{{/isNullable}}
#nullable ^required = nullable, use lambda.optional
{{#isNullable}}{{^required}}{{#lambda.optional}}{{{datatypeWithEnum}}}{{/lambda.optional}}{{/required}}{{/isNullable}}

{{#lambda.camelcase_param}}{{name}}{{/lambda.camelcase_param}}{{#defaultValue}} =

Default value provided, use it or just default
{{^isDateTime}}{{{defaultValue}}}{{/isDateTime}}{{#isDateTime}}default{{/isDateTime}}{{/defaultValue}}

No default value provided, use default
{{^required}}{{^defaultValue}} = default{{/defaultValue}}{{/required}}

{{^-last}}, {{/-last}}{{/readWriteVars}}){{#parent}}
: base({{#parentVars}}{{#lambda.camelcase_param}}{{name}}{{/lambda.camelcase_param}}{{^-last}}, {{/-last}}{{/parentVars}}){{/parent}}

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package 
    ./bin/generate-samples.sh
    ./bin/utils/export_docs_generators.sh
    
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    For Windows users, please run the script in Git BASH.
  • File the PR against the correct branch: master (5.3.0), 6.0.x
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

@wing328
Copy link
Member

wing328 commented Feb 14, 2022

@devhl-labs thanks for the PR. Can you please resolve the merge conflicts when you've time?

@devhl-labs
Copy link
Contributor Author

node1 failure is unrelated.

@wing328 wing328 added this to the 6.0.0 milestone Feb 15, 2022
@wing328 wing328 merged commit d7b812a into OpenAPITools:master Feb 15, 2022
Collections.sort(op.allParams, new Comparator<CodegenParameter>() {
@Override
public int compare(CodegenParameter one, CodegenParameter another) {
if (one.defaultValue == another.defaultValue)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably. Pretty sure we can just remove this if we merge my latest pr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants