Business is slow for Ruby Private Investigator, Deirdre Bug. She’s on the verge of switching industry when she gets a call from an anxious young man. "Some class methods have gone missing," he tells her breathlessly. "I need your help."
Deirdre takes the case and begins exploring Ruby objects behind the scenes. Though she thinks she's on familiar ground — Ruby's object model, method lookup — she's about to discover that she really has no clue.
The talk tells the story of a Ruby Private Investigator recounting one of her most memorable cases. There are specific, technical lessons about singleton classes in Ruby, why they exist, and why knowing about them is useful. However, there are also broader lessons, including the benefits of being inquisitive, the importance of carrying out your own investigations, and the value of understanding the foundations of languages that you use day-to-day. Everyone can take something away from this talk.
The slide deck for the talk is engagingly visual, telling the story through emojis, diagrams, code samples, and video filmed from the terminal.
Here’s an outline of the story:
Section 1
Deirdre has a side gig as a Ruby Private Investigator. She helps her clients solve their coding problems by investigating Ruby’s mysteries.
One day, Deirdre’s acquaintance Mike visits her office. He’s preparing for an important job interview with his best friend, Jenny. They’re working together to compete for one spot — may the best person win.
Jenny has been tasked with researching and writing up notes for method lookup. In her notes she states that: “A method definition always comes from an object's class!”
She has the following code in her notes:
class Cake
…
def tasty?
@flavour == “carrot”
end
def self.edible?
true
end
end
She states that the edible? method is stored on the class Class, since it’s the class of the Cake class.
Doubtful, Mike demonstrates this isn’t true. Deirdre decides to take the case to discover where the edible? method is stored.
Section 2
Deirdre fires up her terminal, searching through all of a Cake class instance ancestors for the edible? method, finding nothing.
Frustrated, she decamps to a co-working space and spots the man next to her playing around with an intriguing module called ObjectSpace.
Playing around with it, she’s surprised to find that when creating a new class, the number of live objects in her Ruby session increments by two. Why two?
Before she can investigate further, she’s called by a friend and remembers that she’s late for a lecture.
Section 3
At the lecture, which is about Smalltalk, Deirdre learns about metaclasses. She also learns that Ruby was inspired by Smalltalk, and that all languages inspired by Smalltalk have their own version of metaclasses.
Newly inspired, Deirdre rushes home to play around in her terminal, discovering the existence of the ‘singleton_class’ method. She soon discovers that the edible? method is stored on the instance of the Cake class’s singleton class. Voilà! Time to celebrate another case solved.
Section 4
Happy with another case solved, yet unsatisfied with her shallow knowledge of singleton classes, Deirdre visits Ellen, her longtime Ruby Investigator mentor. An expert in Ruby’s dark arts, Ellen lights up at the mention of singleton classes. “Aha! Yes, I remember an old case of mine… the client’s codebase was in a mess and I decided I needed to develop a domain-specific language to help. Understanding how singleton classes worked enabled me to develop a compact and elegant solution.” Ellen walks Deirdre through a basic example of what she produced for that client.
Deirdre then heads over to Mike’s place to share the good news. Opening Mike’s door, she finds him crying. It turns out he’s discovered another set of notes that Jenny has been hiding from him — she knew about singleton classes all along and had set him up with the flawed notes in order to steal the job for herself.
Epilogue
Two months later, Deirdre bumps into Ellen at a hack night.
Deirdre tells Ellen, “I’ve been reflecting on the case, and I’m not convinced that Ruby developers need to care about singleton classes.”
Ellen pauses to reflect, then responds, “The day-to-day developer doesn’t really have to. Singleton classes came for a desire for simplicity and consistency from the Ruby Core team. In reality, all methods are instance methods and behave in the same way via singleton classes.”
So no, you don’t really have to care, but they are the foundation of how Ruby methods work: invisible yet everywhere.
I first started working with Ruby almost 5 years ago. Over that time, the concept of singleton classes keeps cropping up. I listened to talks about it, read blog posts, and had fellow Rubyists explain them to me in person. Each time, I came away thinking that I finally understood them, but then I’d find myself confused the next time they came up.
Pat Shaughnessy’s ‘Ruby Under A Microscope’ finally gave me a couple of ‘a-ha’ moments regarding these hidden, yet ever-present, creatures. I’m certainly not the only one who doesn’t fully grasp singleton classes, and I wanted to find a way to share my revelations with a broader audience.
This talk is my attempt at answering the following questions, in a fun, memorable, and engaging way: What are singleton classes? Why do they exist? Do we, as Rubyists, need to care about them at all?
I’ve already given this talk a couple of times — never in the States — and the reception has been positive. The feedback has been that the talk is really enjoyable, because of the heavy reliance on a narrative, yet anyone, from junior to senior developers, can learn something technical from it.