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

Support encoding.BinaryMarshaler/Unmarshaler #40

Open
niemeyer opened this issue Sep 27, 2014 · 6 comments
Open

Support encoding.BinaryMarshaler/Unmarshaler #40

niemeyer opened this issue Sep 27, 2014 · 6 comments

Comments

@niemeyer
Copy link
Contributor

Support the standard marshaling/unmarshaling interfaces from the encoding package:

  • BinaryMarshaler
  • BinaryUnmarshaler
@advance512
Copy link

Is this considerably different from the support that already exists for TextMarshaler/TextUnmarshaler?

What use cases does this have?

@niemeyer
Copy link
Contributor Author

This means supporting types that implement that interface. The support for types that implement a different interface won't make that work.

@lrewega
Copy link

lrewega commented Jan 17, 2019

This is specifically useful for url.URL due to it's inability to implement encoding.TextUnmarshaler until Go 2:

I might take a crack at this.

@niemeyer
Copy link
Contributor Author

The same problem reported as a breakage there also looks like an issue for yaml.

It's a bit of an awkward choice to trust on the binary encoding of the type to present a nice textual representation. I wonder if it will backfire in other cases, where we'd otherwise get a pleasant representation of the fields, and now get some unreadable binary blob.

We might support BinaryMarshaler/Unmarshaler in v3 before it's final, but we'll need to first have a look to understand what the most common conventions are around it.

@mfridman
Copy link

To echo @lrewega, this would be very useful for url.URL support.

@niemeyer v3 landed a few months ago, what are your thoughts on the issue?

@mfridman
Copy link

ping @niemeyer . This has been a long outstanding issue, what are your thoughts on adding support for this?

Any reason not to add this?

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

No branches or pull requests

4 participants