-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
Conversation
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this 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.
Thanks a lot @mvdan |
(see commit messages - please do not squash)