-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add new canvas.RecolorSVG API #5345
base: develop
Are you sure you want to change the base?
Conversation
CI Failures appear to be unrelated flakiness |
internal/svg/svg.go
Outdated
} | ||
|
||
// ColorizeError is the same as Colorize, except returning instead of logging any error. | ||
func ColorizeError(src []byte, clr color.Color) ([]byte, error) { |
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.
Sorry for the pickiness but I'm not sure about the function name here. ColorizeError sounds as if it is changing the colour of an error and not an svg?
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.
Do you have a better name in mind? ColorizeReturnError
?
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.
Not really, no. I think having in the name that something returns an error will be strange. Also the idea of having a version that returns errors and one that doesn't is strange in most cases. I think there are two options:
- Depending on how many call sites there are, it might make sense to only use the version that returns errors and either look at it or ignore it completely.
- The standard library seems to follow the convention that a function always returns an error and in the case where there is a version of it that doesn't, it is called MustXYZ (although the latter usually panics on errors).
It is a bit of a strange pattern in general come to think of it. Any ideas?
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 would agree with 1 - there is little point in exposing the non-error as a public helper API if errors can be generated.
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, this looks like a great new helper
Description:
Fixes #4815
Checklist:
Where applicable: