[ruby-core:123080] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch

Issue #12282 has been updated by zverok (Victor Shepelev).


I'll allow myself to copy-paste my reasoning from the related ticket #14602:

Just a bit of "design space" analysis:

1. I think `dig!` is unusual for core Ruby. A lot of Rubyists are used that in Rails pairs like `find_by`/`find_by!` are raising/non-raising, but I don't remember any Ruby core API using this convention
2. I don't believe the keyword argument is expressive enough. The "visual structure" of the `dig` signature includes multiple values of user data (and the list of values might be of arbitrary length), so the option at the end of arguments is a) not visible enough and b) not immediately intuitively obvious if it isn't part of user's data
3. In Hash, we already have at least two examples of using `fetch` in a sense "get the value or fail": `#[]` vs `#fetch` and `#values_at` vs `#fetch_values`. It seems like it gives enough precedent to look at the "fetch"-based naming, and it seems like `fetch_dig`, while grammatically not ideal, would be guessable enough, based on existing experience.

(...)

I fully agree with @duerst in #14602#note-24: 

> maybe we can think it as a combination of `dig` with `fetch`. Then what about `dig_fetch` or `fetch_dig`? These names don't look very natural, but it's easy to understand what they are about.

First, we **already have examples of `fetch`-based naming**: not only `#fetch` itself as a variation of `#[]`, but also `#fetch_values` as a variation of `#values_at`, so there is a precedent for **recognizability**

Second, I value short one-word names, so all the witty options like `#shovel` and `#retrieve` are nice, but I am afraid that when we have a variation of a known method in an API established long ago, introducing **completely new word** into Ruby would be a false move. Imagine you started to read code and met with `#retrieve` (or `#shovel`) for the first time. There is nothing that might help you to understand what it does; one verb that "a bit resembles `dig`" is not suggestive enough.

Third, `deep_fetch` **is** somewhat suggestive, but the problem "it behaves like `dig`, but the name logic is nothing like `dig`" stands. Maybe if it would a pair of, IDK, `#deep_fetch` and `#deep_get` it might've been tolerable, but now is too late for that, everybody has used to `#dig`.

`fetch_dig`, OTOH, is reasonably short, clearly suggests the meaning, and follows the logic of other methods existing.

----------------------------------------
Feature #12282: Hash#dig! for repeated applications of Hash#fetch
https://bugs.ruby-lang.org/issues/12282#change-114390

* Author: robb (Robb Shecter)
* Status: Open
----------------------------------------
A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario).

Here's how it would work:

~~~ruby
places = { countries: { canada: true } }

places.dig  :countries, :canada  # => true
places.dig! :countries, :canada  # => true

places.dig  :countries, :canada, :ontario  # => nil
places.dig! :countries, :canada, :ontario  # => KeyError: Key not found: :ontario

~~~


Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/