For consistency, please consider using symbolize_keys

ruby/psych#341

@nobu @ioquatix Thanks for the reviews/suggestions. Updated accordingly.

I suggest you add tests to the ruby specs too.

Did Matz already accept this feature?

Did Matz already accept this feature?

Don't think so. We only discussed it with Kazuki in the context of MatchData#deconstruct_keys here.

Okay, let me see if I can pull Matz into the discussion.

Okay, this needs a new issue on bugs.ruby-lang.org. If you can do it, please outline the new feature and link to this PR. It can be brief as this feature is not complex.

Opened a ticket https://bugs.ruby-lang.org/issues/19591 (finally).

Reverted back to symbolize_names as per Matz request.

@palkan do you agree with calling it symbolize_names?

I spent a few days thinking about whether I want to spend energy on this topic.

Honestly, I would like to clarify the naming convention because I don't think JSON symbolize_names is a good standard to follow. So, let's try to standardise the existing convention, e.g. https://bugs.ruby-lang.org/issues/19607 and I will ask Matz about It at the next developer meeting.

Yeah, I’m fine with symbolize_names. That was my original suggestion and I also referred to JSON API; although the naming (“names”) may be not ideal, developers are familiar with it. So, the principle of least surprise works here.

(Also, now I think that symbolize_names is more natural for #named_captures since we already use “named” here, we already refer to these entities as names).

Yeah, named_captures and symbolize_names makes sense to me too.

Regarding JSON, I went and looked at the RFC. They actually refer to it as a name:

An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.

So in this regard, maybe JSON.parse(..., symbolize_names:) makes sense but for different reasons.