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

refactor: add default true type #998

Merged
merged 11 commits into from
Feb 21, 2024
Merged

refactor: add default true type #998

merged 11 commits into from
Feb 21, 2024

Conversation

fchikwekwe
Copy link
Contributor

Which problem is this PR solving?

Short description of the changes

  • adds a DefaultTrue type to use when specifying values with a default of boolean true this improves some getter functions by abstracting away the *bool behavior and allows boolean true be a true default

@fchikwekwe fchikwekwe requested a review from a team as a code owner February 17, 2024 01:10
@fchikwekwe fchikwekwe changed the title Faith/default true fix: add more member funcs for honeycomb logger Feb 17, 2024
@fchikwekwe fchikwekwe changed the title fix: add more member funcs for honeycomb logger refactor: add default true type Feb 17, 2024
@@ -184,6 +184,15 @@ func validateDatatype(k string, v any, typ string) string {
if u.Scheme != "http" && u.Scheme != "https" {
return fmt.Sprintf("field %s (%v) must use an http or https scheme", k, v)
}
case "defaulttrue":
if !isString(v) {
return fmt.Sprintf("field %s must be of type DefaultTrue", k)
Copy link
Contributor

Choose a reason for hiding this comment

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

This error message wouldn't be generated unless the field was of type DefaultTrue. This validation is checking the value portion of the configuration, so you actually want to check if _, ok := v.(bool) to make sure the user is specifying either true or false for the value.

I'm not sure you even need the UnmarshalText part below. But to confirm, you should try a couple of different values in a configuration and run the validator to make sure it does the right thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This value comes in as a string, so I used strconv.ParseBool instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it matters very much but modern YAML parsers want true and false and nothing else, while ParseBool also accepts 1 and 0. The YAML parser we use also accepts things like yes/no and ON/OFF, but only when they're applied to a boolean value (because that was in YAML 1.1, which is now old, but they do it for backwards compatibility).

I like the stricter validation, frankly -- we don't need to support yes/no -- but it might be worth a quick check to see if the YAML parser can read 1/0 into a bool. If not, then our validator should be stricter and just check for true/false and t/f case-insensitively.

Copy link
Contributor Author

@fchikwekwe fchikwekwe Feb 21, 2024

Choose a reason for hiding this comment

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

According the docs, it does not seem that 1/0 are supported as bools in the yaml parser. I'll fix the validation to check for "true"/"false", "t"/"f".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Its a little ugly, but I've updated it.

case bool:
return ""
case string:
if val != "t" && val != "f" && val != "true" && val != "false" {
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use strings.ToLower(val). Another way to do this if you prefer would be something like:

switch strings.ToLower(val) {
case "t", "true", "f", "false":
default:
    // error

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, the second switch statement looks better to me.

Copy link
Contributor

@kentquirk kentquirk left a comment

Choose a reason for hiding this comment

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

Looks good!

@fchikwekwe fchikwekwe merged commit 23fac40 into main Feb 21, 2024
3 checks passed
@fchikwekwe fchikwekwe deleted the faith/default-true branch February 21, 2024 20:44
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

Successfully merging this pull request may close these issues.

Config bools that default to true require more work
2 participants