Allow any instead of custom *Author type#1630
Conversation
asahasrabuddhe
left a comment
There was a problem hiding this comment.
This looks good. Why are the tests failing though?
|
@asahasrabuddhe looks like |
|
@asahasrabuddhe @abitrolly I introduced this because I generally consider using an existing standard library type to be preferable to maintaining our own. Considering the increase in binary size, and that we're not going to be attempting to directly send email with the result of |
|
@meatballhat I think like this issue needs to be addressed upstream somehow. Implementing interface for storing two strings should not result in 500kB increase. Why does this happen? |
@abitrolly wow, yeah, I hadn't thought of it that way! |
|
This change does not make sense considering the increase in binary size. If we find a way like implementing an interface which is still compatible with the standard library and also does not affect the binary size, that's the way to go. |
|
@meatballhat Just revert to old struct it was just 2 fields. Simple and direct or make an interface and add an example in docs of how to use mail.Address with it. |
|
@dearchap I think now that I'd like to use |
|
@meatballhat That would be fine. |
and updated tests to use both strings and *mail.Address
*mail.Address instead of custom *Author typeany instead of custom *Author type
What type of PR is this?
What this PR does / why we need it:
Drop the custom
*Authortype and allowanywith the assumption that it either implementsfmt.Stringeror can otherwise be safelySprintf'd via%s.Which issue(s) this PR fixes:
Supports #1586 given the
*Authortype was defined inapp.gowhich is slated for removal.