jeffparsons / rangemap

Map data structure whose keys are stored as ranges

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Serialize like HashMap

pvshvp-oss opened this issue · comments

Currently, RangeMap and RangeInclusiveMap serialize (using serde) like

((key1start, key1end), value1),
((key2start, key2end), value2),
.
.
((keyNstart, keyNend), valueN)

However, HashMap serializes like

key1:value1,
key2:value2,
.
.
keyN:valueN

Since RangeMap and RangeInclusiveMap are analogous to HashMap, their serialization should preferably be consistent with the convention followed in the implementations coded within the serde crate.

I propose that the serialization be changed to

(key1start,key1end):value1,
(key2start,key2end):value2,
.
.
(keyNstart,keyNend):valueN

which will make it consistent with the convention followed in the serde crate.

(I understand that this will be a breaking change and will probably come with a major version change)

Unfortunately that shape doesn't work well with a lot of formats, e.g. JSON, which only supports strings as keys. For simple key types in a HashMap like integers this isn't toooo bad, because at least there is exactly one obvious string representation of an integer. But when all the keys are ranges, it is less obvious, so I've opted to avoid that source of confusion altogether by going with a list of tuples instead, which works well in all formats.

There's some related discussion here in case you're interested: https://stackoverflow.com/questions/51276896/how-do-i-use-serde-to-serialize-a-hashmap-with-structs-as-keys-to-json

If you have a specific use case where you need it to be serialised in the way you describe, I would suggest making a wrapper struct that serialises it that way based on the values produced by RangeMap::iter. I could potentially provide some similar helper in this crate, but I wouldn't want to change the default serialisation to the way you describe because I think for most users it would simply not work at all.

Sorry to disappoint — it's unfortunately just a bit of a messy problem with no great answers!