When a gemspec wants to express a version requirement, we typically use the `'~> '` notation like this: ```ruby spec.add_dependency 'nokogiri', '~> 1.8' ``` This indicates compatibility following the "rational versioning" as descri...colindkelley (Colin Kelley)
> If #dig returns nil instead of exception, as you want, we cannot distinguish case 2 and case 3. I've looked at a lot of JSON parsing code in Ruby and haven't found examples that were looking to draw that distinction. (Those that do...colindkelley (Colin Kelley)
As described by Matz, it sounds like the implementation would be equivalent to ~~~ def dig(key, *keys) value = self[key] # may raise TypeError if keys.empty? || value.nil? value else value.respond_to?(:dig) ...colindkelley (Colin Kelley)
Here is my suggested documentation on how `Hash#dig` should behave as part of a general `dig` protocol. The patch includes equivalent changes to the documentation for `Array#dig`. ~~~ * Extracts a nested value by navigating the giv...colindkelley (Colin Kelley)
> I'd guess, like Colin, that returning nil is probably the best. Makes debugging harder when writing new code, but makes backward compatibility easier, since old code using dig wouldn't bomb if the data layout changes in the future. ...colindkelley (Colin Kelley)
> I prefer String.new() to "".dup because the former describes intention (of creating a buffer). Ok. I've attached a rev3 patch that uses `String.new` instead of `''.dup`. > ... I had a question about that but I saw it answered els...colindkelley (Colin Kelley)
colindkelley (Colin Kelley)12:45 AM Ruby Revision 8ae24e6b (git): [ruby/psych] issue #443: quote Y and N when dumping