ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "nobu (Nobuyoshi Nakada)" <noreply@ruby-lang.org>
Subject: [ruby-core:119618] [Ruby master Feature#20815] Fetch for nested hash
Date: Fri, 25 Oct 2024 14:32:45 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-110240.20241025143245.54549@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20815.20241025114847.54549@ruby-lang.org>

Issue #20815 has been updated by nobu (Nobuyoshi Nakada).


```ruby
data => user: {profile: {name:}}
p name #=> "Alice"

data => user: {profile: {age:}} #=> NoMatchingPatternKeyError
```


----------------------------------------
Feature #20815: Fetch for nested hash 
https://bugs.ruby-lang.org/issues/20815#change-110240

* Author: dmytrostrukov (Dmytro Strukov)
* Status: Open
----------------------------------------
I propose adding a `fetch_nested` method to Ruby’s Hash class, allowing developers to fetch values deeply nested within a hash, with an error raised if any key in the provided path is missing. The method would be similar to dig, but with the added functionality of error handling when keys are not found, improving code readability and robustness when accessing nested data structures.

**Rationale**

- Enhanced Error Handling: `fetch_nested` would raise an error if a key in the specified path does not exist, which is critical for cases where the absence of specific keys indicates a data integrity issue or invalid structure. This makes debugging easier and helps catch issues early in the development process.
- Improved Code Readability: Without `fetch_nested`, developers often chain multiple fetch calls or rely on error-prone conditional checks, complicating code. A single `fetch_nested` method call would simplify syntax and improve readability when working with deeply nested hashes.
- Alignment with Ruby’s Error-First Philosophy: Ruby’s fetch method already offers error handling for missing keys at the top level of a hash. Extending this philosophy to nested hashes would offer consistency and convenience, aligning with Ruby’s emphasis on developer-friendly and expressive error handling.

**Example Usage**

``` ruby
data = { user: { profile: { name: "Alice" } } }

# Current approach
data.fetch(:user).fetch(:profile).fetch(:name) # Or use dig without error handling

# Proposed `fetch_nested`
data.fetch_nested(:user, :profile, :name) # Raises KeyError if any key is missing

```





-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/

  parent reply	other threads:[~2024-10-25 14:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 11:48 [ruby-core:119614] " dmytrostrukov (Dmytro Strukov) via ruby-core
2024-10-25 13:46 ` [ruby-core:119615] " matheusrich (Matheus Richard) via ruby-core
2024-10-25 14:32 ` nobu (Nobuyoshi Nakada) via ruby-core [this message]
2024-10-26 16:32 ` [ruby-core:119630] " byroot (Jean Boussier) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-110240.20241025143245.54549@ruby-lang.org \
    --to=ruby-core@ml.ruby-lang.org \
    --cc=noreply@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).