Feature #19607: Introduce `Hash#symbolize_keys`.

• Status: Open
• Assignee: -
• Target version: -

[ioquatix (Samuel Williams)]

This is a very common operation.

It can currently be implemented using Hash#transform_keys(&:to_sym).

It's currently provided by Rails as Hash#symbolize_keys and Hash#symbolize_keys!.

Proposed implementation is identical to Rails implementation: https://github.com/rails/rails/blob/539144d2d61770dab66c8643e744441e52538e09/activesupport/lib/active_support/core_ext/hash/keys.rb#L20-L37

For completeness we could also consider adding stringify_keys but I think that's less frequently used.

[ioquatix (Samuel Williams)]

• Tracker changed from Bug to Feature
• Backport deleted (3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN)

[ioquatix (Samuel Williams)]

One part of my motivation for creating this issue is to bring attention to the following inconsistencies:

• https://bugs.ruby-lang.org/issues/15541
• https://bugs.ruby-lang.org/issues/19591

I personally agree with the OP whom stated that symbolize_keys is a much more intuitive option name.

I cannot imagine we would introduce a method on Hash called symbolize_names. So, I think it follows that this was a bad option name, and we should fix it.

[ioquatix (Samuel Williams)]

I did some more research.

The actual JSON RFC https://www.rfc-editor.org/rfc/rfc8259 refers to name/value pairs. So symbolize_names is not so strange for JSON.parse.

In the YAML RFC https://yaml.org/spec/1.2.2/#mapping refers to it as key/value pairs. So symbolize_keys can be more natural, according to the spec, but is inconsistent with JSON. In addition, YAML keys can be different data types e.g. integer, string, symbol, timestamp. In this case, it's not symbolizing all the keys, but just ones which represent names (strings). So, maybe that's also acceptable.

Therefore, I think that those option names are unrelated to symbolize_keys as a method name. But we should not use those options as justification, and instead look for the specific circumstances in each case. That being said, consistency is also useful.

[nobu (Nobuyoshi Nakada)]

ioquatix (Samuel Williams) wrote:

This is a very common operation.

I have never needed such operation.
What’s the use case?

[ioquatix (Samuel Williams)]

https://github.com/search?q=repo%3Arails%2Frails%20symbolize_keys&type=code

or more generally:

https://github.com/search?q=.symbolize_keys&type=code

[nobu (Nobuyoshi Nakada)]

ioquatix (Samuel Williams) wrote in #note-5:

https://github.com/search?q=repo%3Arails%2Frails%20symbolize_keys&type=code

Of course it's imaginable that method is used in Rails since ActiveSupport implements it.
My question is that "is it needed frequently without Rails/ActiveSupport?".

https://github.com/search?q=.symbolize_keys&type=code

They are not copies?

[ioquatix (Samuel Williams)]

The typical implementation transform_keys(&:to_sym) seems fairly common.

https://github.com/search?q=%22transform_keys%28%26%3Ato_sym%29%22&type=code

and

https://github.com/search?q=%22transform_keys%21%28%26%3Ato_sym%29%22&type=code

I suppose we should check whether there can be a significant performance advantage or not. Probably it's minor at best.

[janosch-x (Janosch Müller)]

nobu (Nobuyoshi Nakada) wrote in #note-4:

I have never needed such operation.
What’s the use case?

dealing with data from uncontrolled sources, supporting multiple sources of config data (e.g. YML, JSON, code etc.), and making a less picky interface in general.

some examples:

• faker interface
• pg config
• redis config
• solargraph interface
• interface in ruby/optparse (this is btw another precedent/occurrence of symbolize_names outside JSON and Psych).