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

encoding/json: allow ",string" with json.Marshaler #6350

Closed
gopherbot opened this issue Sep 9, 2013 · 8 comments
Closed

encoding/json: allow ",string" with json.Marshaler #6350

gopherbot opened this issue Sep 9, 2013 · 8 comments

Comments

@gopherbot
Copy link

by nix@google.com:

The current approach to JSON marshalling of bignums is to encode them as huge JSON
numbers. This is technically in compliance with the JSON spec, but not actually
interoperable with other JSON implementations - and interop is the major reason to use
JSON instead of Gob.

I'm wondering if there is any way to revisit this, and marshal big numbers as strings?
Otherwise we are going to have to use wrapper structs around the crypto types so that we
can tack on a custom MarshalJSON implementation.

FWIW, marshalling as strings would also enable the serialization of rational bignums.
@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 1:

I don't believe we can change the default encoding.
If we allow ",string" with json.Marshalers, then you could annotate the *big.Int fields
in your struct with ,string and get the result you wanted.

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

@gopherbot
Copy link
Author

Comment 2 by nix@google.com:

Unfortunately it's not my struct, it's ecdsa.PublicKey (for example).
The only way I can see to fix it in general would be to add a flag to to the JSON
marshaler to make it interoperate with JS clients (such a flag could also affect the
serialization of int64 and uint64). Not a pretty solution though.

@abursavich
Copy link

Comment 3:

How should this work? A JsonMarshaller can return a []byte containing arbitrarily
complex valid JSON.
I threw together a small-ish sample that attempts to illustrate my concerns.  If
consensus can be reached about what this program should output, I might would like to
contribute code for this issue.
http://play.golang.org/p/oQvjnJI5Q4

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 4:

Labels changed: added release-go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 5:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 6:

Labels changed: added repo-main.

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 7:

Given that the ",string" doesn't actually help in the case motivating the original
report and that there is significant complexity (see #3), I think we should drop it.

Status changed to Unfortunate.

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 8:

The workaround here would have to be to have your own ECDSAPublicKey struct with
strings, use that in your data structure, and have converters to/from the standard one.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants