We can think of this as either a variation of `fetch` or a variation of `dig`. Ultimately it's both, of course, just depends how you look at it. If we think of it as `fetch`-based, `deep_fetch` would be OK but we also might go with so...amcaplan (Ariel Caplan)
Thanks, Jeremy! I'm aware that `hash` values can overlap, it was just a shortcut to find problematic situations. In this test, false negatives can happen, but false positives can't. I wasn't aware that there was any scenario where ...amcaplan (Ariel Caplan)
I have a situation where a hash (contained within a Set) seems to get duplicate keys. I've had some difficulty reproducing the issue in a minimal fashion, but I have a 175-ish-line program that runs it. (Just for context, if you want to ...amcaplan (Ariel Caplan)
matz (Yukihiro Matsumoto) wrote: > I am against `dig!` for this purpose. When we have two versions of a method (`foo` and `foo!`), the bang version should be more dangerous than the non-bang version. `dig!` is not the case. > ... I thi...amcaplan (Ariel Caplan)
duerst (Martin Dürst) wrote: > Would a keyword parameter to dig work for you? > ... I appreciate the thought. I personally would be more likely to do `hash.fetch(:name).fetch(:middle)` instead of adding a keyword argument to `#dig`, un...amcaplan (Ariel Caplan)
shevegen (Robert A. Heiler) wrote: > I think this may be somewhat problematic since it does not appear > ... You have a good point about the bang methods often signifying an in-place operation rather than an error-prone one; the latter...amcaplan (Ariel Caplan)
Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ...amcaplan (Ariel Caplan)
Now, to throw in my own opinion: probably the simplest fix would be to circumvent the `#respond_to?` check if we hit `#method_missing?` already - the check is both unnecessary and inaccurate. So probably we'd want the method defining me...amcaplan (Ariel Caplan)
To be more specific (but not clog up the description), the problem can be traced to https://github.com/ruby/ruby/blob/b8d9770b6c699af6e63dab727621777fbfbf7b44/lib/ostruct.rb#L166 where the methods are only defined if `#respond_to?` is `f...amcaplan (Ariel Caplan)
After recent changes to define OpenStruct getter/setter methods lazily, there is a heavy performance impact for the use case where an attribute is assigned at initialization time (i.e. `Openstruct.new(foo: :bar)`). Once an attribute is ...amcaplan (Ariel Caplan)
amcaplan (Ariel Caplan)10:02 PM Ruby Feature #14602: Version of dig that raises error if a key is not present