encoding/json: support int map keys in encoding/json

[allaud]

Our team faced a strange issue with encoding map[int]string into json. Our current solution is to use patched json encoder, which can encode integer keys as strings.

Why not to implement this in the default module?

[minux]

why not add a MarshalJSON method to your map? I don't think encoding/json should handle this special case as it will open up a lot of design questions. What about map[float64]string and map[complex128]string? Should encoding/json also handle those? Which string format should it choose?

[kostya-sh]

Related proposal: #12146

[allaud]

@minux i experience some troubles moving from python to golang as i use integer keys a lot. The python behavior:

>>> d = {1: 1, 5: 4}
>>> json.dumps(d)
'{"1": 1, "5": 4}'
>>> d = {1.4: 1, 5.1: 4}
>>> d
{1.4: 1, 5.1: 4}
>>> json.dumps(d)
'{"1.4": 1, "5.1": 4}'

Maybe we can introduce a special method inside json module for marshalling such data?

[allaud]

I'm speaking about data structures not json

12 сент. 2015 г., в 13:16, Artyom Pervukhin [email protected] написал(а):

Why not to implement this in the default module?

I believe one reason for this is that encoding/json implements RFC 4627, which defines JSON object as

An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.

(emphasis is mine)

—
Reply to this email directly or view it on GitHub.

[cfchris]

This week I added 100+ lines of code to one of our packages to support MarshalJSON and UnmarshalJSON map[int]OurType. I also added 130+ lines of unit tests. While in the standard lib code, I could see it would be far fewer lines based on all of the unexported types and utility functions.

I would love to add this to the standard lib. What is the process for getting an issue approved and assigned?

[rsc]

Did not get to this for Go 1.6, sorry. We should think about this at the same time as #12146.

[cespare]

@rsc, it seems like #12146 is likely to happen, and there's a CL out at https://golang.org/cl/20356.

Given that, you can make your integer keys work but you have to make your own int type with the obvious TextMarshaler/TextUnmarshaler methods.

What are your thoughts about also doing this change? I still think it's worth doing, and I'd like to send a 1.7 CL if you agree.

[cespare]

Bump for @rsc or anyone else with opinions. Shall I send a CL for this?

The change from #12146 has now gone in.

[rsc]

If the change is small and you can make it happen soon, sure.

[cespare]

I'll send a CL in the next couple of days.

[gopherbot]

CL https://golang.org/cl/22060 mentions this issue.