What I didn't know about Ruby Classes

The community is the reason Ruby is amazing. And Matz is one of the nicest guys you’ll ever meet. So genius, yet so humble.

It's interesting, there seem to be two primary camps when people talk about technologies that "bring them joy".

One camp feels this way about maximally-dynamic environments like Lisp and Ruby, which presumably provide "the highest bandwidth" when it comes to translating ideas into code.

Whereas for me and others, it's the exact opposite: these languages create nothing but anxiety. Joyful programming, for me, is programming where I can feel confident and peaceful knowing that every possible contingency of a given piece of code has been either accounted-for or prevented. Knowing that I'm not going to be blindsided by anything, being able to narrow my focus to the problem at hand instead of being overwhelmed with the infinite number of things that could go wrong.

I wonder what causes such a divergence in mindset

i recognize this is a parody of a Zen koan, but I swear to God, it is completely true.

In Ruby they are called "singleton classes", but the actual technical term is metaclass: https://en.wikipedia.org/wiki/Metaclass (check the Ruby entry)

It's like a "shadow class" that's unique to an instance of something. No written description of this concept ever really 'clicked' for me, personally, so maybe an example will help. Here's a class with a single method `:hello` that will simultaneously increment a counter on its class and on its singleton_class/eigenclass/metaclass:

  irb:1* my_class = Class.new do
  irb:2*   def hello
  irb:2*     "I've counted #{self.class.instance_variable_set(:@count, (self.class.instance_variable_get(:@count) || 0) + 1)} of #{self.class}… " +
  irb:2*     "but only #{self.singleton_class.instance_variable_set(:@count, (self.singleton_class.instance_variable_get(:@count) || 0) + 1)} of #{self.singleton_class}!"
  irb:1*   end
  irb:0> end
  irb:0> foo = my_class.new
  irb:0> bar = my_class.new

Then if we send :hello a few times to each instance you can see how it behaves:

  irb:0> foo.hello
  => "I've counted 1 of #<Class:0x0000561efb9d8238>… but only 1 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efbaa8488>>!"
  irb:0> bar.hello
  => "I've counted 2 of #<Class:0x0000561efb9d8238>… but only 1 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efb9d7040>>!"


  irb:0> foo.hello
  => "I've counted 3 of #<Class:0x0000561efb9d8238>… but only 2 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efbaa8488>>!"
  irb:0> bar.hello
  => "I've counted 4 of #<Class:0x0000561efb9d8238>… but only 2 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efb9d7040>>!"


  irb:0> foo.hello
  => "I've counted 5 of #<Class:0x0000561efb9d8238>… but only 3 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efbaa8488>>!"
  irb:0> foo.hello
  => "I've counted 6 of #<Class:0x0000561efb9d8238>… but only 4 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efbaa8488>>!"
  irb:0> foo.hello
  => "I've counted 7 of #<Class:0x0000561efb9d8238>… but only 5 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efbaa8488>>!"
  irb:0> bar.hello
  => "I've counted 8 of #<Class:0x0000561efb9d8238>… but only 3 of #<Class:#<#<Class:0x0000561efb9d8238>:0x0000561efb9d7040>>!"

For a real-world example of how this can be useful, I use this pattern in my Jekyll multimedia toolbox to handle the specifics of any certain type of media file (e.g. images, videos, audio, etc). I defined separate Modules for separate media_type handling, a single instance will detect the media_type of its associated file (from the file extension or filemagic), then the instance will differentiate itself by Module#prepend-ing the media_type-specific Module to the instance's `singleton_class`. Then the next instance for the next possible-different-type media file has a clean undifferentiated base to start from and the process can repeat: https://github.com/okeeblow/DistorteD/blob/master/DistorteD-...

It’s a class dedicated to a single object. Every object has its own eigenclass — this sounds expensive but in practice they’re lazily created. Regular classes are used to store the definitions of methods which are available on all instances of that class. In contrast, a single object’s eigenclass is used to store the definitions of methods which are available on that object only.

`def foo.bar … end` defines a `bar` method in the eigenclass of the object `foo`, which can then be called with `foo.bar`. (This is how “class methods” work in Ruby: their definitions are stored in the class object’s eigenclass so that those methods can be called only on that specific class rather than all classes.)

The language mostly refers to them as "singleton classes", because logically speaking there is exactly one of them for every object.

Every Ruby object is an instance of its singleton class. Even when it appears to be an instance of, say, "File" or "Hash", their true individual identity is their singleton. Hence with:

    class Foo; end
    foo = Foo.new

then

    foo.singleton_class            #=> #<Class:#<Foo:0x00007ff6cc195ee0>>
    foo.singleton_class < Foo      #=> true
    foo.is_a?(foo.singleton_class) #=> true
    foo.singleton_class.ancestors  #=> [#<Class:#<Foo:0x00007ff6cc195ee0>>, Foo, Object, Kernel, BasicObject]

Most significantly, this class is where any per-object method is actually contained, hence:

    class Foo
      def self.hello
        42
      end
    end

    Foo.hello #=> 42
    Foo.singleton_class.instance_methods(false) #=> [:hello]

There are three things worth observing that, once fully absorbed, helped me understand all this more instinctively:

1. All Ruby methods are the instance methods of a class.

2. What we call class methods, such as Foo.hello above, are technically instance methods of the singleton class of a Class object. But that's something of a mouthful, so we say class method instead.

3. Extending an object with a module is, by definition, including that module in the ancestors of its singleton.