Project

General

Profile

Actions

Feature #19607

open

Introduce `Hash#symbolize_keys`.

Added by ioquatix (Samuel Williams) over 1 year ago. Updated over 1 year ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:113285]

Description

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.

Actions #1

Updated by ioquatix (Samuel Williams) over 1 year ago

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

Updated by ioquatix (Samuel Williams) over 1 year ago

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

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.

Updated by ioquatix (Samuel Williams) over 1 year ago

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.

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

ioquatix (Samuel Williams) wrote:

This is a very common operation.

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

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

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?

Updated by ioquatix (Samuel Williams) over 1 year ago

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.

Updated by janosch-x (Janosch Müller) over 1 year ago

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:

Actions

Also available in: Atom PDF

Like1
Like0Like0Like0Like1Like0Like0Like0Like1