Diggin’ and Fetchin’ with TruffleRuby
shopify.engineering
shopify.engineering
{ success: true }[:sucess] is nil (notice that you got a falsy value due to a typo in `success`), while { success: true }.fetch(:sucess) will raise and warn you about your mistake, and Ruby is nice enough to throw a `Did you mean? :success` for you there.
One small tip about fetch: remember that every method in Ruby always fully evaluates all its arguments.
So, if you use it like { data: [ ] }.fetch(:data, get_data_via_very_expensive_method_call), the method `get_data_via_very_expensive_method_call` will always be called, because it's an argument and it will be evaluated BEFORE it's passed to fetch.
That's why one should prefer using the block form in cases like this:
{ data: [ ] }.fetch(:data) { get_data_via_very_expensive_method_call } will only call `get_data_via_very_expensive_method_call` if the Hash doesn't have the :data key.
A shame that refinements don't really get much love, because the third option (in between monkey patching and extending the core library), is to use one of those.
module DigWithFallback
refine Hash do
def dig_fetch(*keys)
# ... impl
end
end
end
class SomeService
using DigWithFallback
def call(params)
params.dig_fetch(:some, :key) { IdentityObject.new }
end
endTheir performance is quite awful on MRI. Any method that was refined is tagged as such, which incur a 40% performance hit (for empty methods)[0]. That alone tend to disqualify them for many use cases.
Then, it might get fixed, but whenever you call `using` all the heap is scanned and all methods caches flushed [1], which is a massive perf hit if it happens often.
TruffleRuby however runs them fast, but since most code out there target MRI, they're not really a good idea except for fringe use cases.
[0] https://gist.github.com/casperisfine/1c46f05cccfa945cd156f44... [1] https://github.com/ruby/ruby/pull/4323
I assumed it is expected overhead.
Note there is also `data[:response][:message] rescue IdentityObject.new` if you don't mind the clumsy exception handler...
Perhaps this is my Perl background showing, but `.fetch` just doesn't feel Ruby-like. Ruby's syntactical terseness around hashes (and regular expressions, with `=~`, `$1`, and friends) is one of my favorite features of the language. If I have to do my hash grabs with a typed word, I might as well be writing Python
To me this is where rails projects can go wrong, when code starts to get too tightly dependent on all kinds of weird options and configured behavior in rails. It makes it difficult to read, even if you're fully versed in all of rails' nooks and crannies, and difficult to modify.