When "stringifying" keys in a map, would you want to convert struct keys to strings?

An issue I can see with the way you’ve shown is that %User{age: 27, name: "john"} and %User{name: "john", age: 27,} represent the same struct, but "%User{age: 27, name: \"john\"}" and "%User{name: \"john\", age: 27}" are different strings. In other words, when in string format the key order becomes relevant. This could be an issue if you’re trying to do lookups using the stringified key. You might be able to avoid it by sorting the keys in the map/struct when you convert it, so that you know age always appears before name in the string.

With structs you should only have atom keys, but there is also a situation where you have a regular map as a key. In this case you would probably approach it the same way as structs, but you would need to consider that this map can itself have maps as keys (which may have maps as keys (which may have maps as keys (which may have…)). So you will need to approach it recursively and could end up with things like: %{%{%{%{\"foo\" => \"bar\"} => \"bax\"} => \"baz\"} => \"biz\"}.

When stringifying the map keys you lose the ability to reliably reverse the map to its original state (was %{"foo" => 1, "bar" => 2} originally %{foo: 1, bar: 2} or %{foo: 1, "bar" => 2}?). This also means that there are several different maps that could stringify into the same value. A map that has all string keys could have originally been a map that contained all atom keys, or a map that contained all string keys and a single atom key, or half and half, etc. If you’re treating atoms and string keys as the same then this might not be an issue, but this leads to situations where two values will have the same string key but would fail an equality check: stringify(foo) == stringify(bar) but bar != foo.

Thank you for the feedback @kylethebaker. Right now, the helper package does handle nested maps.

But I didn’t think about the use case of having a map in a “mixed key type” state (e.g., it contains both strings and atoms) and not beibng able to go back to the original state. All my use cases have been either I need a map with all atom type keys or all string type keys.

And I see your point about structs and key lookups.

Perhaps I shall start with the simplest use case (which is what I’m doing currently) - handle atoms/strings (in nested and non-nested maps) and leave structs and struct-like objects alone…I have to chew on this some more and perhaps others will chime in on their use cases.

There are a few other types to consider as well, namely PIDs, lists, tuples, and functions. I’m not sure how often these would come up in practice. As a shortcut to stringify any of them you can pass the value to inspect/1 and you will get some sort of string representation. I don’t know how useful this string representation would actually be though, I think it depends on the use case.

One thing I noticed in your stringify and atomize functions, you are using the enumerable property of maps to apply the transformation and then casting it back into a map. You can instead use Map.new/2 as a shortcut to do this all at once. For example:

map
|> Enum.map(fn {key, value} -> {stringify_key(key), stringify_value(value)} end)
|> Enum.into(%{})

Can be simply:

Map.new(map, fn {key, value} -> {stringify_key(key), stringify_value(value)} end)

You could always consider using the String.Chars protocol with the Kernel.to_string/1 function and let the implementor of the data type decide if it has a sensible “stringly” representation.