Crystal: Hash.deep_merge

[peterhoeg]

I wrote an extremely basic deep_merge method for Hash as a shard: https://gitlab.com/peterhoeg/deep-merge.cr

Is that something you might want cleaned up and made part of stdlib?

[RX14]

What's the usecase? Also, the types don't work out: https://carc.in/#/r/535k. The types may be able to be worked out using some better code but that would require some hard thinking.

[peterhoeg]

What's the usecase?

To merge nested hashes.

# normal merge
{ "a" => { "b" => 4 } }.merge({ "a" => { "c" => true } })
=> { "a" => { "c" => true } }

# deep merge
{ "a" => { "b" => 4 } }.deep_merge({ "a" => { "c" => true } })
=> { "a" => { "b" => 4, "c" => true } }

Also, the types don't work out: https://carc.in/#/r/535k.

Odd, as I'm using it here - I'm wondering if I tagged the wrong commit. This I need to sort out.

The types may be able to be worked out using some better code but that would require some hard thinking.

Would you in principle be open to adding this to the stdlib? If so, I'll gladly make the necessary changes.

[j8r]

It believe it can be also useful to merge 2 JSON documents in one for example.

[asterite]

I recommend not adding this to the standard library. Reasons:

• the core team has already very limited time to focus on the language itself, the current standard library and windows support
• this method/feature can be kept in a shard and it's easy to add it to a project
• this cab be maintained by people outside the core team (more time for the core team)

In a language where everyone can reopen and add functionality to existing types, adding more and more functionality to the standard library isn't a good choice in my opinion. This is in part related to #5215 (I really wish you would start extracting std features to shards).

[RX14]

To merge nested hashes.

That's not really a usecase, that's just a description of the function. A usecase is another "why" removed, i.e. why do you need to merge nested hashes?

The types only don't work out in some cases: if you're merging Hash(String, Hash(String, String)) and Hash(String, Hash(String, Int32)).

[peterhoeg]

why do you need to merge nested hashes

Specifically in my case to handle a hierarchy of configuration data. You have a set of default settings that get overridden by customer specific config that then gets overridden by user specific config.

I must admit though, that after reading @asterite's comment above, I agree that a slim stdlib is probably the way to go.

[RX14]

Specifically in my case to handle a hierarchy of configuration data. You have a set of default settings that get overridden by customer specific config that then gets overridden by user specific config.

Hashes generally aren't used for storing structured data in crystal, instead classes or records are used instead. Named tuples could work for your usecase though, and the types there might be even harder to get right?

[peterhoeg]

In this particular case, it started out as ruby code where those pesky types weren't getting in the way... ;-)

The config data comes from a bunch of .yaml files and a Hash has worked really well so far instead of creating custom classes but there are of course many ways to skin a cat.

[stronny]

It would be hard if even possible at all to do universally, but it seems realistic in special cases. I did this for JSON because it can only hold some specific classes, maybe it's also true for YAML. I should note that although it compiled and worked I may ended up abusing the language, because at some point the compiler started to break up at random places. Here is the code if you are interested: https://github.com/stronny/bugreport/blob/master/lib/json_tree.cr