One of the most powerful features of Ruby is open classes. You can reopen any class and change, or extend it. Unfortunately these monkey patches have global scope, so their convenience comes with possible side effects. In Ruby 2.1+ refinements allow you to limit the scope of monkey patches, so you can enjoy their convenience again.

blank?

Ruby on Rails brought many monkey patches into mainstream use and they’ve become second nature. For example, ActiveSupport provides a #blank? method on almost every object by monkey patching several standard library classes:

Object#blank? #=> [true, false]
Array#blank? #=> [true, false] alias of Array#empty?
Hash#blank? #=> [true, false] alias of Hash#empty?
String#blank? #=> [true, false] using a regular expression to detect empty and whitespace only strings

NilClass#blank? #=> true
FalseClass#blank? #=> true

TrueClass#blank? #=> false
Numeric#blank? #=> false

Read the source code in ActiveSupport 4.2.0.

What’s your favourite monkey patch in Rails? Maybe it’s "octopus".pluralize, or 3.months.ago?

Rolling your own

#blank? is so handy that we missed it when we started writing a new Ruby app at globaldev. Because we want to avoid dependencies whenever possible, we turned to refinements to roll our own version, tailored to our needs.

In this case, we wanted a convenient syntax for checking parameters in a Rack app. To handle missing or empty parameters we had vanilla Ruby code like:

member_id = String(request.params["member_id"])
if member_id.empty?
  # return 400 Bad Request
end

For our use case we only needed to handle nil and "", so we extended NilClass and String using refinements:

module Blank
  refine String do
    alias_method :blank?, :empty?
  end

  refine NilClass do
    def blank?
      true
    end
  end
end

You can group several refinements in a single module and activate them together in your code. With this refinement we could reduce the boilerplate code for handling parameters to:

using Blank

if request.params["member_id"].blank?
  # return 400 Bad Request
end

Scope

The purpose of refinements is to limit the scope of monkey patches, which should make them easier to reason about and avoid unintended consequences. In addition, refinements must be activated explicitly, which makes it clear when they are active.

The scope of refinements is per file and lexical. You can activate them at the top-level of a file and they will be activated until the end of the file. Or you can activate them inside a class or module and they will be activated until the end of the class or module definition.

Here is an example file showing how our #blank? refinements can be scoped to a single class definition.

require_relative "blank"

class App
  using Blank
  # activated here
  def call(env)
    # here
  end
  # and here
end

# but not here

Read the documentation on ruby-doc.org.

With refinements we can enjoy the wonderful convenience of monkey patching Ruby with less potential for bugs. Enjoy!

P.S. If you’d like to see another example in action. Check out my latest implementation of FizzBuzz using Enumerator and a refinement of Integer.