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

apply gofmt, add new fields to ReviewInput #123

Merged
merged 3 commits into from
Sep 17, 2022

Conversation

mvdan
Copy link
Contributor

@mvdan mvdan commented Sep 15, 2022

(see commit messages - please do not squash)

It fixes up godocs slightly.
In particular, I need ignore_automatic_attention_set_rules,
but I'm adding all other missing fields in the struct too.

I've added RecipientType as a named type, as it's an enum-like string.
@@ -360,6 +366,19 @@ type AttentionSetInfo struct {
Reason string `json:"reason"`
}

type RecipientType string
Copy link
Owner

Choose a reason for hiding this comment

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

As far as I can see, other enum-type strings, we keep as stings.
We don't validate enums here.

What do you think about keeping this as string?
Or maybe: What was the rational behind adding this as its own type?

Copy link
Owner

Choose a reason for hiding this comment

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

Alternatively: Adding https://gerrit-review.googlesource.com/Documentation/user-notify.html#recipient-types as the doc link here might help.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No strong feeling here. I just personally go for named types when it comes to enums; otherwise it's easy to typo a string and have code silently fail. You can't add the named type later on v1+, because that's technically a breaking change, which is why I added it now. I didn't add the constants because those can always be added later.

I don't mind either way though, so I'm OK with deleting if you disagree. Alternatively, happy for you to apply the suggested change and merge.

Copy link
Owner

Choose a reason for hiding this comment

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

I will go with the named type. Thanks @mvdan!

Copy link
Owner

@andygrunwald andygrunwald left a comment

Choose a reason for hiding this comment

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

Thanks a lot!
This change is looking good.
Just the one question about the own enum type. Then we are good to go.

changes.go Outdated Show resolved Hide resolved
@andygrunwald andygrunwald merged commit 2e881e2 into andygrunwald:master Sep 17, 2022
@andygrunwald
Copy link
Owner

Thanks a lot @mvdan

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.

2 participants