From: "byroot (Jean Boussier) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "byroot (Jean Boussier)" <noreply@ruby-lang.org>
Subject: [ruby-core:119630] [Ruby master Feature#20815] Fetch for nested hash
Date: Sat, 26 Oct 2024 16:32:48 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-110252.20241026163248.54549@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20815.20241025114847.54549@ruby-lang.org>
Issue #20815 has been updated by byroot (Jean Boussier).
Status changed from Open to Closed
Closing because it's a duplicate.
----------------------------------------
Feature #20815: Fetch for nested hash
https://bugs.ruby-lang.org/issues/20815#change-110252
* Author: dmytrostrukov (Dmytro Strukov)
* Status: Closed
----------------------------------------
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/
prev parent reply other threads:[~2024-10-26 16: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 ` [ruby-core:119618] " nobu (Nobuyoshi Nakada) via ruby-core
2024-10-26 16:32 ` byroot (Jean Boussier) via ruby-core [this message]
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-110252.20241026163248.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).