Feature #19607
openIntroduce `Hash#symbolize_keys`.
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.
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?".
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:
- 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).