[ruby-core:125339] [Ruby Feature#22012] Data class should respond to #dig
Issue #22012 has been reported by kolbrich (Kevin Olbrich). ---------------------------------------- Feature #22012: Data class should respond to #dig https://bugs.ruby-lang.org/issues/22012 * Author: kolbrich (Kevin Olbrich) * Status: Open ---------------------------------------- `Data`s cousin, `Struct` already responds to `#dig`. `Data` objects can show up in deeply nested objects as well, and the semantics of this should be nearly identical to `Struct#dig` -- https://bugs.ruby-lang.org/
Issue #22012 has been updated by zverok (Victor Shepelev). This was a conscious design decision on Data implementaion, that underlines its nature. Struct has a two-fold nature: it is both "a mutable structured object" and "a container" (has `#[]`, `#each`, includes `Enumerable`). Data is a base for composite value objects; so in designing it, the focus was on other composite value objects in Ruby, like Time. We don't have `Time.now.dig(:year)` and things like that, making a distinction between "navigable containers" and "atomic value objects". If `Data`-based class used in some context as a base of a container-like object, the implementation of `#dig` is relatively trivial: ```ruby class Locations < Data.define(:work, :home, :shelter) def dig(first, *rest) return unless members.include?(first) send(first).then { rest.empty? ? it : it.dig(*rest) } end end ``` ---------------------------------------- Feature #22012: Data class should respond to #dig https://bugs.ruby-lang.org/issues/22012#change-117095 * Author: kolbrich (Kevin Olbrich) * Status: Open ---------------------------------------- `Data`s cousin, `Struct` already responds to `#dig`. `Data` objects can show up in deeply nested objects as well, and the semantics of this should be nearly identical to `Struct#dig` -- https://bugs.ruby-lang.org/
Issue #22012 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed Thank you for the proposal, and thank you @zverok for the detailed explanation. I agree with @zverok. The absence of `#dig` on `Data` is intentional. `Data` is designed as a base for composite value objects, not as a navigable container. This is the same reason it does not have `#[]`, `#each`, or `Enumerable`. The `dig` family (`Hash#dig`, `Array#dig`, `Struct#dig`) is built for objects that expose `#[]` for element access. `Data` deliberately does not provide `#[]`, so adding `#dig` alone would be inconsistent with the rest of the language. I would also like to keep `Data`'s API small. When a `Data`-based class is used in a container-like role, defining `#dig` yourself is straightforward, as @zverok showed. So I will decline this one. Thank you again for thinking it through. Matz ---------------------------------------- Feature #22012: Data class should respond to #dig https://bugs.ruby-lang.org/issues/22012#change-117324 * Author: kolbrich (Kevin Olbrich) * Status: Closed ---------------------------------------- `Data`s cousin, `Struct` already responds to `#dig`. `Data` objects can show up in deeply nested objects as well, and the semantics of this should be nearly identical to `Struct#dig` -- https://bugs.ruby-lang.org/
participants (3)
-
kolbrich (Kevin Olbrich) -
matz (Yukihiro Matsumoto)
-
zverok (Victor Shepelev)