Project

General

Profile

Feature #16274

Transform hash keys by a hash

Added by sawa (Tsuyoshi Sawada) 25 days ago. Updated 24 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:<unknown>]

Description

We have Hash#transform_keys and its bang version to change the keys of a hash, but that requires passing a block, which assumes that the mapping from the old keys to the new keys follows some rule. But in reality, we frequently want to change the keys where it is difficult to provide a rule. For example, suppose we have:

hash = {created: 2019-10-23 17:54:46 +0900, updated: 2019-10-23 17:59:18 +0900, author: "foo"}

and want to achieve:

{created_at: 2019-10-23 17:54:46 +0900, update_time: 2019-10-23 17:59:18 +0900, author: "foo"}

I request an option to change the keys of a hash not by giving a block, but by passing a hash. I came up with two options.

1. Argument for Hash#transform_keys and its bang version

Allow Hash#transform_keys to optionally take a hash argument instead of a block.

hash.transform_keys({created: :created_at, updated: :update_time})
# => {created_at: 2019-10-23 17:54:46 +0900, update_time: 2019-10-23 17:59:18 +0900, author: "foo"}

2. Argument for Hash#slice and the counterparts in other classes

Since Hash#slice is often the first step of modifying a hash into some other hash form, it makes sense to let it take an optional hash argument.

hash.slice(:created, :author, transform_keys: {created: :created_at})
# => {created_at: 2019-10-23 17:54:46 +0900, author: "foo"}

With option 1, it could make sense to even allow a hash argument and a block simultaneously:

hash.transform_keys({created: :created_at, updated: :update_time}, &:to_s)
# => {"created_at" => 2019-10-23 17:54:46 +0900, "update_time" => 2019-10-23 17:59:18 +0900, "author" => "foo"}

History

#1

Updated by sawa (Tsuyoshi Sawada) 25 days ago

  • Description updated (diff)
#2

Updated by sawa (Tsuyoshi Sawada) 25 days ago

  • Description updated (diff)

Updated by shyouhei (Shyouhei Urabe) 25 days ago

Understand the motivation (maybe that of #slice can be separated into another request).

One quick question: what should happen if both a block and an argument are passed at once?

#4

Updated by sawa (Tsuyoshi Sawada) 25 days ago

  • Description updated (diff)

Updated by sawa (Tsuyoshi Sawada) 25 days ago

shyouhei (Shyouhei Urabe) wrote:

Understand the motivation (maybe that of #slice can be separated into another request).

One quick question: what should happen if both a block and an argument are passed at once?

Actually, I just came up with an additional idea regarding that exact point. Updated the issue.

#6

Updated by sawa (Tsuyoshi Sawada) 25 days ago

  • Description updated (diff)

Updated by duerst (Martin Dürst) 25 days ago

String#gsub also can take a block or a hash. Using a hash for String#gsub isn't possible in Perl or Python, but can be extremely handy. Maybe the behavior when there's both a block and a hash could be the same as for String#gsub?

Updated by shevegen (Robert A. Heiler) 24 days ago

Personally I have had a need to transform keys (and values) in a hash quite a bit. We
also have strange thingies such as HashWithIndifferentAccess so that may be indicative
of people wondering about strings/symbols as keys for a hash in general. :)

To sawa's suggestion: if the choice is solely between option 1 and option 2,
I personally would favour 1, mostly because I only rarely use slice in
general (primarily I may use slice in regards to String, but even then I tend
to prefer e. g. [] start, end positions normally, even if it may not be the
same, such as if we include .slice!() use cases). But this may differ on
an individual choice, by different ruby users, so I can not generalize it;
it is only an opinion if the choice is purely between #1 and #2 alone.

I do not know how frequent the use case may be, but ignoring this for the
moment I think this suggestion may be useful.

Also available in: Atom PDF