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

Parameter Verification for RepoConfiguration and CliArguments #2121

Open
asdfghjkxd opened this issue Feb 17, 2024 · 0 comments
Open

Parameter Verification for RepoConfiguration and CliArguments #2121

asdfghjkxd opened this issue Feb 17, 2024 · 0 comments

Comments

@asdfghjkxd
Copy link
Contributor

asdfghjkxd commented Feb 17, 2024

What feature(s) would you like to see in RepoSense

Previously, due to the constructors used in RepoConfiguration and CliArguments, only legal combinations of parameters were permitted in the construction of RepoConfiguration and CliArguments objects.

However, with the Builder pattern, this restriction in parameter combination is lifted, and hence there is a need to validate if the combination of provided parameters is legal.

Is the feature request related to a problem?

This issue is related to issues #2076, #2117 and #2119 and PR #2078.

If possible, describe the solution

We should first ascertain the legal parameter combinations for both RepoConfiguration and CliArguments, before implementing a method such as validate() to check if the provided parameters follow some established legal combination of parameters, before the Builder object builds the RepoConfiguration or CliArguments object.

If applicable, describe alternatives you've considered

One alternative we could consider would be providing documentation on what parameter combinations are valid, and explicitly warning users that deviations from these combinations may result in errors. This puts the burden of correctness on the user, and it assumes that the users are knowledgeable enough to know what combinations of parameters they would require to get their work done.

Alternatively, we could ascertain that certain mandatory parameters that the user is required to fill in are indeed filled in, and leverage the existing default values currently in use to ensure that other required parameters, if omitted, have a default value to fall back on if necessary.

Additional context

N/A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant