DEV Community: Alex Vondrak

On RSpec, Minitest, and Doing Magic Right

Alex Vondrak — Fri, 08 May 2020 04:19:16 +0000

I started programming Ruby professionally in 2014, which meant I had to learn RSpec. To this day, it remains the de facto standard for writing tests. And to this day, I still don't really get it.

Back then, I didn't get how to use it: contexts, hooks, expectations, mocks. It's a lot to learn, especially for inexperienced programmers. Still, I persisted. I fumbled my way through the syntax. Resources like the RSpec Style Guide taught me some conventions. I wrote test suites large enough to leverage features like shared examples and custom matchers.

Nowadays, I don't get why to use RSpec in the first place. Is it because the DSL reads vaguely like English? Is it because the output is human readable? Is it because, in the words of one of its developers, "it reifies so many testing concepts into first class objects"?

Those are the things RSpec says on the tin, anyway. I don't fully get why they're virtues. And to the extent that they are, I don't see how RSpec delivers well on any of them.

The DSL

The Ruby community at large is enamored with DSLs, be it Sinatra, Whenever, Rake, Chef, or things that probably don't even count. One of the most common criticisms of DSLs is that they're "magic".

But I think the problem with RSpec is exactly the opposite: it's not actually magic. If it were magic, I would be able to read it and not know what it's doing underneath. But in order to make sense of any of it, I have to know how it's implemented.

Take the following example.

RSpec.describe Article do
  subject(:article) { described_class.new(title: title) }
  let(:title) { Faker::Lorem.sentence }

  describe '#header' do
    subject(:header) { article.header }

    def words_in(sentence)
      sentence.gsub(/[[:punct:]]/, '').split
    end

    context 'when the title is over 50 characters long' do
      let(:title) { Faker::Lorem.paragraph_by_chars(number: 100) }

      it 'gets truncated' do
        expect(header.length).to be <= 50
        expect(header).to end_with('...')
      end

      it 'keeps words intact' do
        expect(words_in(title)).to match_array(words_in(header))
      end
    end
  end
end

Pretty standard RSpec code, right? It's not even doing anything fancy. Yet already I have to grok several things:

RSpec.describe is used at the top level to avoid namespace pollution.
Inside the block, you have to use just describe.
Example groups are essentially syntactic sugar for defining classes.
Knowing this, I remember you can define arbitrary helper methods.
Similarly, I think about how subject and let translate down into memoized methods.

And then there are the matchers... When I first started learning RSpec, I always got the syntax wrong. Where do the dots go? the spaces? the underscores? the parentheses? In order to keep any of it straight, I had to know the actual implementation.

I still can't make sense of expect(header.length).to be <= 50 without the extra mental work of parsing it in my head. I don't see the English, I see Ruby, and my brain has to be the interpreter.

expect(header.length).to be <= 50
#=> expect(header.length).to(be.<=(50))

expectation = expect(header.length)
#=> RSpec::Expectations::ExpectationTarget.new(header.length)

matcher = be
#=> RSpec::Matchers::BuiltIn::Be.new

matcher = matcher.<=(50)
#=> RSpec::Matchers::BuiltIn::BeComparedTo.new(50, :<=)

expectation.to(matcher)
#=> ...

I can't help but see all the guts. And as used to RSpec as I am, it still trips me up. Or at best, it slows me down:

I know end_with and match_array by heart as some of the many built-in matchers. But the list is long; I still find myself having to look it up.
Some matchers have to evaluate an expression multiple times, so you need to wrap things in blocks. Even more punctuation to get in the way of your "English-y" syntax, like expect { counter.increment }.to change { counter.value }.from(0).to(1).
There are infinitely many predicate matchers, since they use method_missing to delegate to the expectation target. Imagine the frustration of junior me, unable to find any documentation on some weird-looking matcher I saw in the wild, only to find it was calling a method dynamically.
If be_xxx wasn't enough, there could be custom matchers, noun-phrase aliases, or negated matchers floating around the namespace. I've wasted a not-insignificant amount of time hunting down the names & implementations of matchers littered around the test suite.

So why even bother with this language in the first place? I still have to understand it in terms of the Ruby it seeks to abstract. This isn't magic. It's a leaky abstraction.

The Documentation

I guess even if I don't find the code readable, the output is pretty legible.

Array
  behaves like a collection
    initialized with 3 items
      says it has three items
    #include?
      with an item that is in the collection
        returns true
      with an item that is not in the collection
        returns false

Is it really useful, though?

To start, it's barely proper English (even ignoring flagrant misuse of RSpec's syntax, like it "uniqueness of title"). If you were asked about an array's behavior, would you say "Array behaves like a collection initialized with 3 items says it has three items" out loud? The indentation is what implies any complete sentence structure: "Array behaves like a collection, so when it's initialized with 3 items, it says it has three items".

The output's structure, of course, comes from the nested context blocks + implied its when you read the code. But I know that when I'm looking for a failed example, I'm rarely able to trace the convoluted sentence back through some deep nesting of contexts. I'm just going to rely on the line numbers reported at the end of the run. For that matter, I'm just going to be using the progress bar format anyway. 🤷

I hear rumors of these BDD teams where specs are shared between technical & nontechnical folk alike, forming an executable set of human-readable requirements that everyone can agree on. It sounds nice in theory. I've never worked on such a team, so I'm speaking out of my depth. But I can't help noticing that RSpec is still used wholesale for everything from acceptance tests down to unit tests. It's even considered good style to keep example descriptions short and use class/method names. Short descriptions are hardly conducive to thorough documentation. And should your nontechnical team really be caring about the code on the classes-and-methods level? I highly doubt it.

If you're going to do something, do it right. At least with Cucumber you could write honest-to-god executable documentation in complete sentences and paragraphs. Even RSpec's docs are generated this way. Again, I've never actually been on a team that does this; but RSpec strikes me as a half-measure by comparison.

The Magic

So if programmers are the only ones who truly care about the tests at the level they're being written with RSpec, why not use something simpler? Well, maybe RSpec is just that gosh dang powerful. I mean, the library certainly does a whole lot of stuff.

But then there's Minitest, the standard foil to RSpec. It shows how the same testing can still be done in plain old Ruby. RSpec's general syntax can readily be transliterated to classes & methods. That way, you don't have to learn a new language to write your tests.

class ArticleTest < Minitest::Test
  def article
    @article ||= Article.new(title: title)
  end

  def title
    @title ||= Fake::Lorem.sentence
  end

  class Header < self
    def header
      @header ||= article.header
    end

    def words_in(sentence)
      sentence.gsub(/[[:punct:]]/, '').split
    end

    class WhenTheTitleIsOver50CharacterLong < self
      def title
        @title ||= Faker::Lorem.paragraph_by_chars(number: 100)
      end

      def test_it_gets_truncated
        # ...
      end

      def test_it_keeps_words_intact
        # ...
      end
    end
  end
end

Granted, the nesting is so awkward that you usually won't do this in Minitest. A more faithful translation would probably be flatter, with simpler method names. (This is an advantage, if you ask me.) Then, instead of using the expectations syntax, Minitest::Test defines assertion methods that your class will inherit.

class ArticleTest < Minitest::Test
  def words_in(sentence)
    sentence.gsub(/[[:punct:]]/, '').split
  end

  def test_long_headers_get_truncated
    article = Article.new(title: Faker::Lorem.paragraph_by_chars(number: 100))
    assert_operator article.header.length, :<=, 50
    assert article.header.end_with?('...')
  end

  def test_header_keeps_words_intact
    title = Faker::Lorem.paragraph_by_chars(number: 100)
    words = words_in(title)
    article = Article.new(title: title)
    words_in(article.header).each do |word|
      assert_includes words, word, <<~MSG
        #{word.inspect} is in the header #{article.header.inspect}
        but not in the title #{article.title.inspect}
      MSG
    end
  end
end

The "first class features" of matchers are generally "first class features" of Minitest—or indeed, the Ruby programming language.

Negation is done with the refute_* counterparts to assert_*.
Customized messages can be given as the last argument to any Minitest assertion (except assert_output), as demonstrated above.
Custom matchers simply become Ruby methods that delegate to the Minitest assert_* primitives.
Compound expectations could just as well be separate assertions for conjunction (assert one; assert two) or plain boolean operators for disjunction (assert one || two, 'neither one nor two').

Similarly, RSpec hooks that Minitest excludes can be accomplished with plain Ruby. Shared contexts & example groups can be arranged as modules and classes. RSpec mocks are more or less comparable to Minitest's equivalents. By and large, Minitest doesn't reinvent Ruby's wheel.

Furthermore, almost just to prove that it's possible, Minitest implements essentially a subset of RSpec's DSL. But no matter how small its implementation (a dubious virtue), I have the same distaste for it as I do for RSpec. Why bother in the first place?

The one thing I'll give RSpec is that strings are easier to type out than coming up with test_* method names. But you don't need a whole framework to achieve this. ActiveSupport::TestCase has a lightweight test method that's almost literally def with a string.

class ArticleTest < ActiveSupport::TestCase
  def words_in(sentence)
    # ...
  end

  test 'long headers get truncated' do
    # ...
  end

  test 'header keeps words intact' do
    # ...
  end
end

ArticleTest.instance_methods - ActiveSupport::TestCase.instance_methods #=> [
#   :test_long_headers_get_truncated,
#   :test_header_keeps_words_intact,
#   :words_in,
# ]

The times I do need to group together tests, I admittedly miss having context. For that, you could use something as beautifully small as minitest-context or as relatively big as shoulda-context.

Going further, Minitest plugins fill in various gaps. minitest-around gives you around hooks. minitest-metadata gives you metadata (which I've personally never actually needed). minitest-reporters gives you nicer output akin to RSpec's formatters. And so on.

I agree that all this patchwork isn't a great experience out of the box. Even basic CLI tooling is hand-rolled. So you aren't really comparing RSpec to just Minitest; you're comparing it to Minitest and an ecosystem of plugins & boilerplate. Be that as it may, RSpec's killer features are met by this ecosystem—plus a dose of basic Ruby programming skills. Perhaps it's less cohesive, but I don't think you're throwing the baby out with the bathwater by ditching RSpec.

Magic Done Wrong

Complex problems often demand complex solutions. But RSpec is the sort of complexity that increases cognitive load. If you're going to lean into the so-called magic, why would you use it to make your job harder?

I believe it's possible to use magic for good. To do something complex in order to make something simple.

I don't even think Minitest accomplishes this. If you were to ask around, it'd certainly be perceived as less "magic", and it is less complicated than a spec-style DSL. But you still carry a lot of mental weight:

assert_same uses equal?, but assert_equal uses ==, and assert_nil has to be used explicitly come Minitest 6.
Remember to use the order assert_equal expect, actual for nicer failure messages.
And it's assert_includes collection, object, not assert_includes object, collection.
Oh yeah, assert_predicate exists. Maybe I should use that for better failure messages instead of assert object.predicate?.
Does anyone else always have to think about what assert_in_epsilon means, or is it just me?
I've made the mistake before of thinking assert_raises "message" does an assert_equal "message", e.message, but it's just the Minitest failure message. Oops. 😅
Stubbing is (purposefully) painful. I definitely avoid it—I've been burned enough times by bad stubs. But sometimes I legitimately need it, and making the process more restrictive doesn't help.

Much like I have to open up RSpec's docs to figure out how to use it, I regularly crack open Minitest's source code to remember how a certain method works (usually the stubbing). Minitest is a breath of fresh air compared to RSpec, but I have to admit the mental drag is still there years after adopting it.

Magic Done Right

So what does qualify as good magic?

It wasn't until I used pytest in a Python project that it clicked. Specifically, all of its assertions are written plainly as Python assert statements. (Although its fixtures are pretty fuckin' cool, too.)

We could do the same in Minitest, saying assert a == b instead of assert_equal a, b. But the whole problem is that we won't get useful output when something fails. The plain assert is being passed in a boolean, so its failure would look like

Minitest::Assertion: Expected false to be truthy.

whereas the assert_equal could say

Minitest::Assertion: Expected: 1
  Actual: 2

So what pytest does is rewrite the whole damn program behind the scenes to decorate every assert with rich diffs. You, the tester, needn't be any the wiser. If your test fails, you just get a useful error message. You don't have to remember the difference between assert_same and assert_equal, or the order of arguments to assert_includes. Its complexity is entirely hidden from you, provides concrete value, and it doesn't ask anything special in return. How's that for magic?

The closest Ruby version I've seen is Power Assert, which combs over a Ruby expression so you get thorough output like

Failure:
   assert { 3.times.to_a.include?(3) }
              |     |    |
              |     |    false
              |     [0, 1, 2]
              #<Enumerator: 3:times>

I haven't had a chance to convert my existing Minitest suites over to see how well this works in practice. The project comes with some strong caveats that make me hesitant to try, though.

Programming language & library designers should really be taking heed. All these RSpec vs Minitest debates are tired—they've been raging years longer than I've even been programming Ruby. Power Assert & pytest have to go through great lengths to get something resembling good output without burdening the programmer. A good language design can make this much easier.

One example is Elixir. The ExUnit framework is simple but powerful, and its implementation is relatively straightforward due to Elixir's macros. ExUnit.Case gives you the describe/test pair—a light dusting of DSL, like ActiveSupport::TestCase but with more functionality. Then ExUnit.Assertions defines the assert macro, which introspects its arguments at compile-time so you get better failure reporting. The fact that it can even do this is a testament to the language's design.

It's still arguably complex. After all, someone had to implement everything that goes into supporting macros. Maybe programming is just magic all the way down. I only ask that your magic doesn't shift the burden onto me.

Classes & Inheritance: Unweaving the Rainbow

Alex Vondrak — Sat, 02 May 2020 22:44:03 +0000

Philosophy will clip an Angel's wings,
Conquer all mysteries by rule and line,
Empty the haunted air, and gnomed mine–
Unweave a rainbow, as it erewhile made

— Lamia (John Keats)

I'm an academic at heart. I don't think that's a bad thing for a software engineer, but it gets kind of lonely.

I notice it when phone screening. As an interviewer, I might ask something about object-oriented design. "Can you tell me how inheritance works?" Typically, I'll hear answers about code reuse, subclasses delegating to superclasses, quirks of specific programming languages, composition over inheritance, etc.

These answers aren't wrong. But I die a little bit inside when it's all I hear. The academic part of me yearns for more depth. In my experience, most programmers can describe what inheritance does, but not what it really is.

Nineteenth-century poet John Keats purportedly quipped that scientist Issac Newton "destroyed the poetry of the rainbow by reducing it to a prism". And sure, learning how a magic trick works might rob you of a certain joy. But I think the broader programming community would do well not to treat language constructs as magic tricks—as some syntactic incantation you just learn by rote. Not only can there be a joy in knowing, there are practical benefits to digging deeper. You'll take the lessons learned with you on all your future programming endeavors.

So instead of waiting to hear it from an interviewee like some secret academic handshake, I want to educate. Let's destroy a rainbow together.

Classes

You can't take two steps in Programming Town without tripping over object orientation: C++, C#, Java, Kotlin, Perl, PHP, Python, Ruby, Scala, Swift, ... The syntax, nomenclature, and other gory details vary, but I'll assume you're familiar with the ideas in general. The gist being: you define your own classes of objects (the nouns of your program) that then contain constructors, variables, methods, etc. An individual object constructed by the class is called an instance, and the instance's methods are what do the main work of your program.

While this post isn't really specific to any language, Ruby is a quintessential example of an object-oriented language, so I'll go ahead and use it for the code throughout. Let's define a simple class.

class Rainbow
  attr_reader :colors

  def initialize(colors)
    @colors = colors
  end
end

The Rainbow class has an initializer that takes in an array of colors and saves them in an instance variable. That variable is accessible by a corresponding getter method.

To represent the individual colors in a rainbow, we define yet another class.

class Color
  attr_reader :alpha

  def transparent?
    alpha == 0.0
  end

  def translucent?
    0.0 < alpha && alpha < 1.0
  end

  def opaque?
    alpha == 1.0
  end
end

To make things interesting, we define the Color class with an alpha channel—a percentage used to represent the opacity of a pixel when we render the color. Not only do we have a getter method for this alpha, we define several methods implementing logic involving its value.

So far, so good. But we can't really construct a meaningful color yet. The problem is that there are several different ways to represent colors in a computer. That's where we'll use inheritance.

Inheritance

The term "inheritance" is meant to evoke the concept of genetics. When children inherit traits from their parents, the parents don't lose those traits. Children may also have additional traits beyond the ones they've inherited.

So, too, can we propagate traits between classes in a program. We define subclasses that inherit from superclasses. Inherit what, though? Generally, the methods and variables. Features like access modifiers (e.g., private in Ruby) change which exact things get inherited, but the details aren't relevant to this post.

Defining a subclass is largely the same as defining a standard class.

class RGB < Color
  attr_reader :red
  attr_reader :green
  attr_reader :blue

  def initialize(red, green, blue, alpha = 1.0)
    @red = red
    @green = green
    @blue = blue
    @alpha = alpha
  end
end

The RGB class is a subclass of Color (and Color is a superclass of RGB). It represents a point in the RGB color model: three values between 0 and 255 for the redness, greenness, and blueness of a pixel. Combined, these 3 primary colors add together to form a secondary color, ranging from black (0, 0, 0) to white (255, 255, 255).

Using RGB, we can finally instantiate meaningful colors.

red = RGB.new(255, 0, 0)
orange = RGB.new(255, 165, 0)
yellow = RGB.new(255, 255, 0)
green = RGB.new(0, 255, 0)
blue = RGB.new(0, 0, 255)
indigo = RGB.new(75, 0, 130)
violet = RGB.new(238, 130, 238)

Due to inheritance, every instance of RGB responds to methods defined by Color. This is how inheritance promotes code reuse: basically by "copying" code (if only virtually) so you don't have to.

dimmed_red = RGB.new(255, 0, 0, 0.5)
dimmed_red.transparent? #=> false
dimmed_red.translucent? #=> true
dimmed_red.opaque? #=> false

We can keep defining more subclasses, and even subclasses of those subclasses.

class Cylindrical < Color
  attr_reader :hue
  attr_reader :saturation
  attr_reader :component

  def initialize(hue, saturation, component, alpha = 1.0)
    @hue = hue
    @saturation = saturation
    @component = component
    @alpha = alpha
  end
end

class HSL < Cylindrical
  alias lightness component
end

class HSV < Cylindrical
  alias value component
end

The Cylindrical class is another subclass of Color. It is a generalized representation of a point in a cylindrical-coordinate color model. Such a color has three pieces: a hue represented as an angle between 0-360°, a saturation between 0 and 1, and a third component whose name & possible values vary by the specific model.

Some examples of such models are given by the Cylindrical subclasses HSL (hue, saturation, lightness) and HSV (hue, saturation, value). They inherit the getters for hue and saturation, as well as the getter for the generic third component. But component isn't very descriptive, so each subclass aliases it, creating a getter with a more specific name.

We can represent a color like forest green using equivalent instances of each class.

rgb = RGB.new(34, 139, 34)
hsl = HSL.new(120, 0.61, 0.34)
hsv = HSV.new(120, 0.76, 0.55)

Even more color models exist, but digging into all of them isn't the sort of rainbow wrecking I had in mind. 😉

Classes unwoven

My point is that, as programmers, we know how to define classes mechanistically in our language of choice. In fact, there's quite a lot we know about how to use them: writing initializers, instantiating objects, making getter methods over instance variables, defining methods that use those values. You probably know even more than what I'm summarizing here. The Rainbow class and all the different Color classes are pretty humdrum in most languages.

But if we know classes merely by how we use them, then a class is whatever our language makes of it—all the syntax, semantics, patterns, and boilerplate. In Python, you use explicit selfs. In Java, you have to be mindful about the difference between int and Integer. In C++, initialization is bonkers. In Kotlin, you need to declare a class open to allow subclasses. In Go, methods are declared separately from structs, which only have a limited form of inheritance via embedding. And so on.

Really, I want to highlight the difference between the imperative and the declarative—doing vs being. Programming languages implement classes as a feature that does something for you in some specific way. But they only bother because of what a class is in the abstract, which doesn't change between languages. So what is a class, really?

My answer may seem underwhelming: a class can be understood as a set of all its possible instances.

For illustration, the RGB class contains not just the ROYGBIV instances we created before, but also every other valid instance. Using just the red/blue/green components, that's 256^3 = 16,777,216 possible combinations. Along with the alpha channel, which is a real number between 0 and 1, there is an uncountably infinite number of elements in this set (although computers can only represent a finite range of floating point numbers in practice).

The exciting part of pulling on this thread is that it leads us to the very foundations of mathematics. Virtually all mathematical theorems can be formulated as theorems of set theory. Thanks to over a century of work by mathematicians, we know a wide variety of abstract properties about sets. Things that are true not because of a specific implementation, but because they must be true.

Inheritance unwoven

One such truth: if classes are sets, then subclasses are subsets. One set is a subset of another if every element of the first is also an element of the second. In mathematical notation, we write $\in S$ if element $x$ is a member of set $S$ and we write $\subseteq T$ if set $S$ is a subset of set $T$ . So $\subseteq T$ if for every $\in S$ it's the case that $\in T$ as well.

When an object-oriented language says "everything is an object", one thing they often mean is that every class inherits from some base Object superclass. Considering all the classes we've defined so far, we can draw the Venn diagram showing how these sets nest.

Elements of the Object set include the elements of the Rainbow and Color sets. Inside of Color are all its possible instances; some of those instances are also in the RGB and Cylindrical sets. Inside Cylindrical are HSL and HSV.

In mathematical notation:

\begin{aligned} \texttt{Rainbow} &\subseteq \texttt{Object} \\ \texttt{Color} &\subseteq \texttt{Object} \\ \texttt{RGB} &\subseteq \texttt{Color} \\ \texttt{Cylindrical} &\subseteq \texttt{Color} \\ \texttt{HSL} &\subseteq \texttt{Cylindrical} \\ \texttt{HSV} &\subseteq \texttt{Cylindrical} \\ \end{aligned}

Now consider an instance of the HSL class for the color pink.

pink = HSL.new(350, 1.0, 0.88)

We can say that pink is in the HSL set. By the definition of subsets, this also means the following.

\begin{aligned} \texttt{pink} &\in \texttt{HSL} \\ \texttt{pink} &\in \texttt{Cylindrical} \\ \texttt{pink} &\in \texttt{Color} \\ \texttt{pink} &\in \texttt{Object} \\ \texttt{pink} &\notin \texttt{Rainbow} \\ \texttt{pink} &\notin \texttt{RGB} \\ \texttt{pink} &\notin \texttt{HSV} \\ \end{aligned}

Given these set memberships, and the fact that classes are sets of instances, this means pink is an instance of HSL, Cylindrical, and Color simultaneously.

Methods

These interactions become important when we consider what methods mean through the lens of subsets. Say we add a method to the RGB class that returns the corresponding complementary color.

class RGB < Color
  def complement
    self.class.new(255 - red, 255 - green, 255 - blue, alpha)
  end
end

We think of this method as taking no arguments. After all, we pass the message to an instance of RGB with no parameters.

red = RGB.new(255, 0, 0)
cyan = red.complement # RGB 0, 255, 255

If we try to call this method on some other class that does not define it, we get an error.

red = HSL.new(0, 1.0, 0.5)
red.complement #=> NoMethodError

Imagine for a moment that the language didn't have this concept of methods, though: just top-level functions. The spelling might be different, but you could achieve the same effect. In our example, if an instance is in the RGB class, we can use the logic as defined; otherwise raise an exception.

def complement(o)
  case o.class
  when RGB
    o.class.new(255 - o.red, 255 - o.green, 255 - o.blue, o.alpha)
  else
    raise NoMethodError
  end
end

A method is then a function whose first argument is tacitly an instance of the class on which it's defined. This is made more evident in languages like Python, where methods are always defined with an explicit first argument named self.

But conceptually, using just one function gets more complicated. Methods with the same name might be defined for several different classes. So if we only have this one function, it needs to have a branch for each class on which it's defined.

Say we added an equivalent method for Cylindrical.

class Cylindrical < Color
  def complement
    self.class.new((hue + 180) % 360, saturation, component, alpha)
  end
end

The top-level function would need an extra clause for the Cylindrical case.

def complement(o)
  case o.class
  when RGB
    o.class.new(255 - o.red, 255 - o.green, 255 - o.blue, o.alpha)
  when Cylindrical
    o.class.new((o.hue + 180) % 360, o.saturation, o.component, o.alpha)
  else
    raise NoMethodError
  end
end

But this implementation still incorrect, thanks to inheritance. In the above code, we're checking set equality. As was pointed out in the previous section, an instance can be a member of multiple sets at once, even if the sets aren't equal. For example, even though an instance of HSL is also an instance of Cylindrical, $HSL≠Cylindrical\texttt{HSL} \ne \texttt{Cylindrical}$ . Yet the actual method is equally valid to call on subclasses of Cylindrical.

red = HSL.new(0, 1.0, 0.5)
cyan = red.complement # HSL 180, 1.0, 0.5

green = HSV.new(120, 1.0, 0.50)
purple = green.complement # HSV 300, 1.0, 0.5

We know classes are sets. So instead of checking if the object's class is equal to the definer's class, what if we perform a subset check, $⊆\subseteq$ ? In Ruby, you can actually compare two classes this way using the <= operator.

def complement(o)
  case
  when o.class <= RGB
    o.class.new(255 - o.red, 255 - o.green, 255 - o.blue, o.alpha)
  when o.class <= Cylindrical
    o.class.new((o.hue + 180) % 360, o.saturation, o.component, o.alpha)
  else
    raise NoMethodError
  end
end

Finally, this is a correct definition for our complementary color method. Languages don't necessarily implement methods this way, but that doesn't invalidate the conceptual understanding.

Method overriding

Things get more complicated when we throw method overriding into the mix. This allows a subclass to redefine a method of their parent class. The subclass can usually delegate to the original superclass method with some form of super keyword, but this feature complicates our discussion too much for the scope of this post. I encourage you to destroy that rainbow for yourself. 😉

One common (though admittedly not particularly interesting) pattern in Ruby, which lacks explicit abstract classes, is to define a method that raises NotImplementedError on the superclass. Subclasses are expected to override the method, because otherwise they'll inherit the error-throwing version. This is desirable simply for the fact that NotImplementedError is more informative than NoMethodError.

For example, we might expect to be able to convert cylindrical-coordinate colors into RGB points. However, the implementation details vary based on the specific cylindrical model.

class Cylindrical
  def to_rgb
    raise NotImplementedError
  end
end

class HSL < Cylindrical
  def to_rgb
    puts '(HSL to RGB algorithm)'
  end
end

class HSV < Cylindrical
  def to_rgb
    puts '(HSV to RGB algorithm)'
  end
end

If we subclass Cylindrical without overriding the method, we're tipped off to the fact that we didn't implement something we should have.

class HSI < Cylindrical
  alias intensity component
end

magenta = HSI.new(300, 1.0, 0.67)
magenta.to_rgb #=> NotImplementedError

Once again, for the sake of illustration, let's think about how we would define this method as a function that compares subsets. This isn't how languages necessarily implement it, but it helps us understand how we might get the logic wrong.

def to_rgb(o)
  case
  when o.class <= Cylindrical
    raise NotImplementedError
  when o.class <= HSL
    puts '(HSL to RGB algorithm)'
  when o.class <= HSV
    puts '(HSV to RGB algorithm)'
  else
    raise NoMethodError
  end
end

The issue is that our big conditional statement is sensitive to the order of the branches. In the incorrect implementation above, the Cylindrical subset check is done first. So say we pass an HSL instance into this top-level function. Since $HSL⊆Cylindrical\texttt{HSL} \subseteq \texttt{Cylindrical}$ , we'll immediately execute the branch that raises the NotImplementedError.

coral = HSL.new(5, 0.90, 0.72)
to_rgb(coral) #=> NotImplementedError

So we need to order the branches correctly. How do we know we can even find such an ordering? Because of set theory!

Firstly, a partial order of a given set is a relationship between any two of its elements such that the following properties hold.

Reflexivity: every element is related to itself.
Antisymmetry: any two distinct elements related to each other in one direction cannot be related in the other direction. Said another way, the only way two elements can be related in both directions is if they're actually the same element.
Transitivity: if one element is related to a second element and the second is related to a third, then the first is related to the third as well.

For example, the set of integers is partially ordered by the "less than or equal to" relationship.

Every integer $x$ is less than or equal to itself: $\le x$ .
If $\le y$ and $\le x$ , then $x = y$ .
If $\le y$ and $\le z$ , then $\le z$ .

So, too, is the set of classes (in Ruby, this would be the Class class) partially ordered by the "is a subset of" relationship, $⊆\subseteq$ .

Every set is a subset of itself: $\subseteq A$ .
If $\subseteq B$ and $\subseteq A$ , then $A = B$ .
If $\subseteq B$ and $\subseteq C$ , then $\subseteq C$ .

But a key difference between $≤\le$ and $⊆\subseteq$ is that "less than or equal to" is a total order on its corresponding set (i.e., integers). This means the relationship satisfies one additional property.

Connexity: any two elements must be related in some direction.

Given any two integers $x$ and $y$ , either $\le y$ or $\le x$ . That is, integers are always comparable.

However, the subset relationship is not a total order. Although some sets are subsets of others, there are disjoint sets with nothing in common. We can't say HSL is a subset of HSV or vice versa; RGB is not a subclass of Cylindrical, nor is Cylindrical a subclass of RGB. So classes aren't always comparable.

This matters because we'd like to order our conditional branches correctly. We must be able to sort classes such that the "smallest", most specific subset is first—so that HSL & HSV come before Cylindrical. But if $⊆\subseteq$ is not a total order, how can we sort classes relative to each other? What order do HSL & HSV go in, since they're not comparable?

The answer is not to use a traditional comparison sorting algorithm that CS majors learn so much about in school. Rather, we can use topological sorting. Theory tells us that for any partial order there exists at least one topological ordering. Incomparable elements may appear in any order relative to each other, as long as they come before/after comparable elements as appropriate.

Any such ordering is sufficient for our current example. One possible topological ordering puts HSL before HSV.

def to_rgb(o)
  case
  when o.class <= HSL
    puts '(HSL to RGB algorithm)'
  when o.class <= HSV
    puts '(HSV to RGB algorithm)'
  when o.class <= Cylindrical
    raise NotImplementedError
  else
    raise NoMethodError
  end
end

Just as valid would be to put HSV before HSL. As long as they both come before their superset Cylindrical, the topological ordering keeps us from executing the wrong logic.

def to_rgb(o)
  case
  when o.class <= HSV
    puts '(HSV to RGB algorithm)'
  when o.class <= HSL
    puts '(HSL to RGB algorithm)'
  when o.class <= Cylindrical
    raise NotImplementedError
  else
    raise NoMethodError
  end
end

This might seem trivial. Our classes all have one immediate superset, so we can readily see this "straight line" topological order from HSV to Cylindrical to Color to Object. Never fear: there's still more rainbow left to untangle.

Multiple inheritance

Where the topological order matters more is in when a subclass can have several superclasses, as is the case with multiple inheritance.

Languages don't seem to advertise their multiple inheritance loudly. If you ask me, it's a case of no true Scotsman. Many languages have some form of multiple inheritance, they just won't call it that. They implement different limitations & algorithms to handle some of the ambiguities that can arise, making their flavor of multiple inheritance different from "pure" multiple inheritance—whatever that means. As a result, trying to understand the concept in terms of any one language will be difficult: Ruby's approach will lead you one way while Python's will lead you another. Once again, it serves us to think about the topic in the abstract (and not too pedantically).

In terms of sets, multiple inheritance declares that a class is a subset of the union of multiple superclasses. The union of sets $S$ and $T$ , denoted $\cup T$ , is a set such that if $\in S$ or $\in T$ , then $\in S \cup T$ .

In Ruby terms, you can't inherit from multiple classes. But you can mix-in multiple modules. In the language, modules differ from classes in that they don't have instances. That is, you can't call M.new for a module M. However, the two are still very much related. In fact, Class is a subclass of Module in Ruby. Realizing this, it's not a stretch to think that modules are still sets. If you can conceptualize classes as sets of instances, a module might be a set of objects that respond to certain methods. Despite the technical differences, the conceptual effect is the same: the child acquires traits from multiple parents.

So you want a convoluted example? You've got it! We'll first define modules how we normally would in Ruby, then think again about how methods could theoretically be implemented as top-level functions.

Let's say we have some shared functionality for objects that are suitable subjects of poetry. According to Keats, this might include an angel's wings, gnomed mines, and of course rainbows. For us to write a poem about any given object, we might need to compute properties about it, like words that rhyme with the object's name or the source of its artistic beauty.

module Poetic
  def rhymes
    puts '(Poetic rhymes algorithm)'
  end

  def beauty
    puts '(Poetic beauty algorithm)'
  end
end

While angels, gnomes, and rainbows aren't subclasses of each other, we can factor out their shared poetic functionality.

Compare this to cold, calculating science. In science, we care about objects that we can measure. As Keats laments, all the object's mysteries will be conquered by rule and line. But to a scientist, the beauty is in knowing.

module Scientific
  def measurements
    puts '(Scientific measurements algorithm)'
  end

  def beauty
    puts '(Scientific beauty algorithm)'
  end
end

Any number of objects might have scientific functionality, but we care primarily about rainbows. Moreover, a rainbow is both a poetic and a scientific phenomenon.

class Rainbow
  include Poetic
  include Scientific
end

The spelling might be different from subclassing, but this declares that Rainbow is a subset of the union of Poetic and Scientific.

In mathematical notation, $Rainbow⊆Poetic∪Scientific\texttt{Rainbow} \subseteq \texttt{Poetic} \cup \texttt{Scientific}$ . In Ruby, you can even compare the sets the same way as before.

Rainbow <= Poetic #=> true
Rainbow <= Scientific #=> true

Defining the functional logic of the unique methods is simple.

def rhymes(o)
  case
  when o.class <= Poetic
    puts '(Poetic rhymes algorithm)'
  else
    raise NoMethodError
  end
end

def measurements(o)
  case
  when o.class <= Scientific
    puts '(Scientific measurements algorithm)'
  else
    raise NoMethodError
  end
end

However, what do we do about the beauty function, whose method is defined for both Scientific and Poetic? Even though a topological sort would put Rainbow before either of these modules, Scientific and Poetic themselves are incomparable. So the behavior is dependent on the order.

def beauty(o)
  case
  when o.class <= Poetic
    puts '(Poetic beauty algorithm)'
  when o.class <= Scientific
    puts '(Scientific beauty algorithm)'
  else
    raise NoMethodError
  end
end

rainbow = Rainbow.new([red, orange, yellow, green, blue, indigo, violet])
beauty(rainbow) #=> (Poetic beauty algorithm)

With Poetic before Scientific, the poetic algorithm is used on the Rainbow instance.

def beauty(o)
  case
  when o.class <= Scientific
    puts '(Scientific beauty algorithm)'
  when o.class <= Poetic
    puts '(Poetic beauty algorithm)'
  else
    raise NoMethodError
  end
end

rainbow = Rainbow.new([red, orange, yellow, green, blue, indigo, violet])
beauty(rainbow) #=> (Scientific beauty algorithm)

With Scientific before Poetic, the scientific algorithm is used on the Rainbow instance.

In a way, our topological sort has failed us: either of the above could be valid. This is where language implementations resolve the ambiguity in different ways—sometimes even as full-fledged features.

In Ruby, classes may mix in multiple modules. include inserts the module directly after the current class in the topological order, so a more recent include has higher precedence than a less recent one. prepend inserts a module directly before the current class in the topological order, which allows for some interesting patterns.
In Common Lisp (CLOS), classes may have multiple parents. Generic functions sort applicable methods with tie-breakers based on the declaration order. This list can be applied in standard or customized ways.
In Scala, classes may mix in multiple traits. The spec defines a standard class linearization that winds up working similarly to Ruby's, where the order of declarations matters.
In Python, classes may inherit from any number of parent classes. The method resolution order (MRO) is given by the C3 linearization algorithm.
In Factor, ambiguities in the class linearization are resolved through a couple different tie-breaking rules based on metaclasses & lexicographic order.
And so on.

There's no right answer. But knowing the abstract problem helps you to better understand the algorithms used by your favorite language.

Types

I'd be remiss not to mention type theory, since we're used to dealing with various notions of types in programming languages.

If you dig into set theory and the foundations of mathematics, you'll find various equivalent formalisms. While there is ostensibly a difference between a subclass and a subtype, in practice I think it's largely pedantic. At any rate, the theories of sets and types are equivalent. That being the case, it's still useful for programmers to think of a classes as sets, sets as types, and thus classes as types.

For example, a practical concept that falls out of this kind of thinking is the difference between has-a and is-a relationships. Intuitively, a rainbow is not a type of color, but RGB is. However, a rainbow contains many colors. Thus, Rainbow should use a has-a (or really, has-many) relationship to Color by keeping objects in instance variables, whereas RGB should use an is-a relationship by subclassing Color. But you don't even need to know the buzzwords if you can think critically about the types (and therefore classes) involved in your program. Doing so means you're actively thinking about how to write good code. And that's a skill transferable to any language, whatever the subclassing (or subtyping) mechanisms might be.

This also means that despite whatever misconceptions people may have, even a dynamic language like Ruby has types. After all, it has classes. Just because one language doesn't use the same type-checking algorithms as another, it doesn't mean that types cease to exist. They're there abstractly even if your language doesn't call them out by name. As such, it still behooves you to think about types in a general sense, whether you're writing dynamically-typed PHP or statically-typed Java.

Conversely, even functional languages that we don't normally think of as object-oriented have the same theoretical underpinnings. Instead of full-blown classes you might see a construct like Elixir's defstruct, which defines a type with specific fields but no methods. Or there may be very sophisticated ways of defining custom types, as in Haskell's algebraic data types. Such types might include something like Racket's anonymous unions, allowing us to formulate multiple inheritance in terms of type constraints. And as we've seen, rather than attach methods to specific classes, you could define functions that dispatch based on the type of their first argument. But why stop there? A system like CLOS can use multiple dispatch to select the most specific function to apply to the combination of parameters. Of course, you could also be OCaml and fuse object orientation with the type system & syntax of the functional language ML.

Programming languages vary widely, but the concepts can still be understood in general terms. If you understand the general, then learning any specific language—and writing good code in it—becomes that much easier.

Rainbows unwoven

So there it is. Classes & inheritance analyzed to death; the underlying theory exposed. Armed with this knowledge, what have you lost? If you ask me, not the beauty, but the preconceptions.

Object orientation isn't at odds with functional programming. Either can be understood (at least at a high level) in terms of the other.
Mixins, multiple inheritance, and union types are more similar than they are different.
Even among object-oriented languages, one system isn't fundamentally different from another. They're all different flavors of set theory.

A major benefit of abstraction is unifying ideas into an elegant whole that can be kept in your head. If you understand that classes are sets, and you already know how sets behave, you're capable of grokking a wide variety of object-oriented systems. Language becomes an implementation detail.

But despite what you might automatically think that means, implementation does matter. Each object system is beautiful in some way. Taking advantage of your language's strengths makes your job easier as a programmer. Playing to these strengths lets you organize your code in beautiful ways. What could be more important?

[W]e want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

— Structure and Interpretation of Computer Programs

So go forth and destroy some rainbows. You never know what you might learn. 🌈