@@ -1,9 +1,19 @@
 ---
 title: From Singleton to Legion
 date: 2006-07-22
-published: false
 ---
 
+> **Update, November 2026:** Ruby 1.9.2 added `Kernel#singleton_class`,
+> which made "singleton class" the official name. Ruby still keeps a single
+> singleton class per object, so on an unpatched Ruby the second `def o.x`
+> below replaces the first, and its `super` raises `NoMethodError`. But
+> Ruby 2.0 added `Module#prepend`, and prepending a module to the singleton
+> class gives much the same layering: after
+> `o.singleton_class.prepend(Module.new { def x; super + "x"; end })`,
+> `o.x` returns `"xx"`. Facets carried both `eigenclass` and `qua_class` as
+> `Kernel` methods. Facets 3.2 deprecated them in favor of `singleton_class`
+> or Facets' `meta_class`, and they will be removed after 2027-09-30.
+
 <!-- ---
 title: From Singleton to Legion
 date: "2016-07-22"
@@ -15,11 +25,11 @@ For as long as I've coded Ruby there has been some question as to the appropriat
 
 While the term is fitting in the sense that each object only has one of these classes (hence "single"), issues arise from a terminology clash with an already well accepted object-oriented programming term, [Singleton Pattern](http://en.wikipedia.org/wiki/Singleton_pattern). In OOP-speak a singleton class is a class that can only be instantiated once. Many have argued that the Singleton pattern itself is a flawed concept, since one can just instantiate an object and assign it to a constant to achieve the same end. So why restrict anyone from a second instance of a class if they so choose? That's a reasonable argument, although not always as practical as it might seem. Nonetheless, the terminology clash still remains.
 
-In light of nomenclature issue, many have offered alternative terms for Ruby's singleton class. Indeed, Ruby itself has used two alternatives in the past: virtual class and metaclass, and many people still prefer that later of these choices. Other suggestions include the well known _whyism `eigenclass`, the abbreviated `sclass`, the pronoun contingents 'myclass' and 'ownclass', as well as my own concoctions `adhoc` and `qua_class`. Yet despite all these names, none of which ever stick, what is this singly thing really?
+In light of nomenclature issue, many have offered alternative terms for Ruby's singleton class. Indeed, Ruby itself has used two alternatives in the past: virtual class and metaclass, and many people still prefer the latter of these choices. Other suggestions include the well known _whyism `eigenclass`, the abbreviated `sclass`, the pronoun contingents 'myclass' and 'ownclass', as well as my own concoctions `adhoc` and `qua_class`. Yet despite all these names, none of which ever stick, what is this singly thing really?
 
-Recently, our beloved Pit Capitan put it concisely when he said "there are only two types of methods in Ruby, instance methods and singleton methods". Well said. Unfortunately it's not quite true. Instance methods aren't really methods at all, they are just definitions for methods to be. That's why when you use `#instance_method` you get something called an `UnboundMethod`, not a `Method`. It only becomes a method when it's bound to an object. To clarify further how that distinction is a bit misleading, consider that when a singleton method is defined it falls into an inheritance hierarchy along side so-called instance methods. In other words, the singleton methods and instance methods exist on the same playing field, and the former can call on the other via `#super`. In fact, we can access these singleton methods in instance fashion via `(class<<obj;self;end).instance_method(sym)`. So these methods are not really distinct in this manner after all. In fact there is no distinction between methods other than bound and unbound. And this distinction arises from the capability of class Module and class Class to harbor a set of method definitions that are not their own. Which is of course exactly why these constructs exist in the first place. So when we say singleton method, we are not referring to something different from instance method. We only mean that these methods are kept in a special "singleton class", made just for a specific object, and consequently, are automatically bound to that object.
+Recently, our beloved Pit Capitain put it concisely when he said "there are only two types of methods in Ruby, instance methods and singleton methods". Well said. Unfortunately it's not quite true. Instance methods aren't really methods at all, they are just definitions for methods to be. That's why when you use `#instance_method` you get something called an `UnboundMethod`, not a `Method`. It only becomes a method when it's bound to an object. To clarify further how that distinction is a bit misleading, consider that when a singleton method is defined it falls into an inheritance hierarchy alongside so-called instance methods. In other words, the singleton methods and instance methods exist on the same playing field, and the former can call on the other via `#super`. In fact, we can access these singleton methods in instance fashion via `(class<<obj;self;end).instance_method(sym)`. So these methods are not really distinct in this manner after all. In fact there is no distinction between methods other than bound and unbound. And this distinction arises from the capability of class Module and class Class to harbor a set of method definitions that are not their own. Which is of course exactly why these constructs exist in the first place. So when we say singleton method, we are not referring to something different from instance method. We only mean that these methods are kept in a special "singleton class", made just for a specific object, and consequently, are automatically bound to that object.
 
-Now, I'm going to claim that the term 'singleton' is a poor choice for a completely different reason than any given before. It may come as a bit of surprise, but singletons are not inherently single. They are only made so by an explicit restriction in the Ruby's source code. It is quite simple, actually, to remark-out the if-clause from the source, recompile Ruby and then do:
+Now, I'm going to claim that the term 'singleton' is a poor choice for a completely different reason than any given before. It may come as a bit of surprise, but singletons are not inherently single. They are only made so by an explicit restriction in Ruby's source code. It is quite simple, actually, to remark-out the if-clause from the source, recompile Ruby and then do:
 
 ```ruby
 o = Object.new
@@ -32,8 +42,8 @@ end
 o.x   => "xx"
 ```
 
-The reason Ruby makes the per-object classes single is because it would be terribly inefficient to define a whole new class for every new singleton method defined. That's understandable, but it also comes at a cost. We can not reliably receive an object from the outside world and define our own singleton on it because we may be clobbering someone else's singleton method without even knowing it. (NOTE: It doesn't matter so much if you're just redefining a method altogether, but if you're calling super it very much matters.) Generally we don't even think about such things, but truth be told, object singleton methods often fail to survive code refactoring. Object singleton's really only exist as a side effect of Ruby's class model (and Smalltalk's?) which utilize the singleton class as a means of separating a module/class method definitions from it's own actual methods. This could have been done another way of course, but then a class/module would be something wholly different from any other object. The use of the singleton allowed classes and modules to be just like any other object. So singletons are really a bit of cleverness that lie at the very heart of how Ruby works.
+The reason Ruby makes the per-object classes single is because it would be terribly inefficient to define a whole new class for every new singleton method defined. That's understandable, but it also comes at a cost. We can not reliably receive an object from the outside world and define our own singleton on it because we may be clobbering someone else's singleton method without even knowing it. (NOTE: It doesn't matter so much if you're just redefining a method altogether, but if you're calling super it very much matters.) Generally we don't even think about such things, but truth be told, object singleton methods often fail to survive code refactoring. Object singletons really only exist as a side effect of Ruby's class model (and Smalltalk's?) which utilize the singleton class as a means of separating a module/class method definitions from its own actual methods. This could have been done another way of course, but then a class/module would be something wholly different from any other object. The use of the singleton allowed classes and modules to be just like any other object. So singletons are really a bit of cleverness that lie at the very heart of how Ruby works.
 
-Does it mean that they have to be singly? Could we remove the restriction and open up a additional robustness to these per-object classes? We could. In fact, this was the very first hack I ever made to the Ruby source code. My change simply checked to see if the method was already defined in the first "singleton" layer and continue upward until it either found a usable layer or ran out of layers, in which case it created a new one. Combined with the capability to selectively undefine particular methods of particular layers and we gain a flexible pre-object class hierarchy system that can be used without the caveats that currently make singletons so limited outside of class and module definitions.
+Does it mean that they have to be singly? Could we remove the restriction and open up an additional robustness to these per-object classes? We could. In fact, this was the very first hack I ever made to the Ruby source code. My change simply checked to see if the method was already defined in the first "singleton" layer and continue upward until it either found a usable layer or ran out of layers, in which case it created a new one. Combined with the capability to selectively undefine particular methods of particular layers and we gain a flexible per-object class hierarchy system that can be used without the caveats that currently make singletons so limited outside of class and module definitions.
 
-And then we no long can call them "singleton" but rather "legion" ;)
+And then we no longer can call them "singleton" but rather "legion" ;)
@@ -1,9 +1,23 @@
 ---
 title: Main is a DRY Pain
 date: 2006-08-17
-published: false
 ---
 
+> **Update, November 2026:** Ruby 2.0 gave `main` a `define_method` of its
+> own, which defines a method on `Object`, so the first error below no
+> longer happens, though `main` still has no `ancestors`. Ruby 2.0 also
+> made `main`'s `include`, `public` and `private` private methods, so on
+> Ruby 3.4 the `public_methods` comparison below returns `[]`, and
+> `singleton_methods` returns only `[:to_s, :inspect]`. Ruby 3.0 fixed the
+> Module Inclusion Problem ([#9573](https://bugs.ruby-lang.org/issues/9573)):
+> a module included into `Kernel` now reaches every object, so in the last
+> example both `m` and `Q.new.q` return `"m"`. Methods defined in `main`'s
+> singleton class are still not visible anywhere else, as the `class << self`
+> example shows. I've corrected the method name in that example's error
+> message, which said `s`. I took up the question of `main` as a
+> self-extended module again in
+> [Kill the Proxy and Save Toplevel]({{ site.baseurl }}{% post_url 2012-06-17-kill-the-proxy-and-save-toplevel %}).
+
 <!-- ---
 title: Main is a DRY Pain
 date: "2006-08-17"
@@ -19,7 +33,7 @@ That seems fairly peculiar when you consider that defining methods at toplevel i
 self    #=> main
 ```
 
-Okay, it calls itself "main". Great. But that doesn't really tell us anything. Let's check it's class:
+Okay, it calls itself "main". Great. But that doesn't really tell us anything. Let's check its class:
 
 ```ruby
 self.class  #=> Object
@@ -46,7 +60,7 @@ class Q
 end
 
 Q.new.q
-#=> NameError: undefined local variable or method 's' for #<Q:0xb7ce9a3c>
+#=> NameError: undefined local variable or method `x' for #<Q:0xb7ce9a3c>
 ```
 
 Which means the sure solution for my problem...
@@ -79,6 +93,6 @@ Q.new.q
 #=> NameError: undefined local variable or method `m' for #<Q:0xb7cbb324>
 ```
 
-Lands me squre in the face of the Module Inclusion Problem.
+Lands me square in the face of the Module Inclusion Problem.
 
 All this leads me to two points. First, I'm stuck! There seems to be no solution to my problem other than rewriting a second version of my module specifically for the toplevel. Talk about lack of DRY! And 2) Why in the world isn't main a self extended module?
@@ -1,15 +1,27 @@
 ---
 title: Vote Kernel for Toplevel Object
 date: 2006-08-18
-published: false
 ---
 
+> **Update, November 2026:** Ruby 2.0 added the kind of top-level method
+> matz mentions below: `main` now has its own private `define_method`,
+> which defines methods on `Object`. Because `main` finds its own
+> `define_method` first, the example below never calls the hand-written one.
+> It still prints `true` and `false`, though, because `main` is still not
+> `Object`. Taskable didn't last in
+> Facets: by version 1.8 (January 2007), taskable.rb had been dropped
+> because its "implementation won't work as toplevel include". For a while
+> Facets also had main_as_module.rb (later main.rb), which made `main` act
+> more like a module; Facets 2.9.3 spun it off as the main_like_module gem.
+> Ruby's top level is still not a module. I took up the idea again in
+> [Kill the Proxy and Save Toplevel]({{ site.baseurl }}{% post_url 2012-06-17-kill-the-proxy-and-save-toplevel %}).
+
 As a follow up to my last post on the "pain that is main", I want to offer a potential improvement for Ruby 2.0. I approached the topic on ruby-talk this week and while Matz initially took some interest, he hasn't followed up since his last comment:
 
     matz: Why?  If it is really required it's fairly
     easy to add toplevel methods like we did for #include.
 
-But it isn't always easy. In order get my Taskable module to work, for instance, I had to make exceptions for the toplevel case, which is far from ideal and is fragile [Ed- in fact I'm still getting bugs that I haven't yet pinned down]. These subtile difficulties arise becuase main acts as a partial proxy for the Object class. Anyone who has created a proxy object before knows the subtile issues that can come into play. In this case, only the bare minimal interface is supported --essentially the method #include. Yet, even if we take matz' advice and add in all the missing proxy methods, we still won't be 100% out of the woods. The Object class and main are fundamentally two distinct objects --self is not the same, nor are their singleton classes, &c. In the vast majority of cases this will never present an issue, but the distinction can creep in. Here's an highlight of one way it can:
+But it isn't always easy. In order to get my Taskable module to work, for instance, I had to make exceptions for the toplevel case, which is far from ideal and is fragile [Ed- in fact I'm still getting bugs that I haven't yet pinned down]. These subtle difficulties arise because main acts as a partial proxy for the Object class. Anyone who has created a proxy object before knows the subtle issues that can come into play. In this case, only the bare minimal interface is supported --essentially the method #include. Yet, even if we take matz' advice and add in all the missing proxy methods, we still won't be 100% out of the woods. The Object class and main are fundamentally two distinct objects --self is not the same, nor are their singleton classes, &c. In the vast majority of cases this will never present an issue, but the distinction can creep in. Here's a highlight of one way it can:
 
 ```ruby
 module Q
@@ -50,9 +62,9 @@ true
 false
 ```
 
-So in effect Ruby is mildly schizophrenic. The false reading is because main != Object. So, you can't necessarily create a DSL for Object to be used in main, and you can't neccessairly create a DSL for main to be used in any Object. Hence the devolution to DRYless code.
+So in effect Ruby is mildly schizophrenic. The false reading is because main != Object. So, you can't necessarily create a DSL for Object to be used in main, and you can't necessarily create a DSL for main to be used in any Object. Hence the devolution to DRYless code.
 
-There is a potentially elegant solution however, and I'd really like to understand others insights into this (especially Matz' of course): Instead of main being a special proxy object, just let it be a self extended module.
+There is a potentially elegant solution however, and I'd really like to understand others' insights into this (especially Matz' of course): Instead of main being a special proxy object, just let it be a self extended module.
 
 ```ruby
 module Main
@@ -61,15 +73,15 @@ module Main
 end
 ```
 
-This would provide all the facilities required of the toplevel without all the proxy troubles. Also, while I'm not so convinced of the merits of every toplevel method becoming a private method of all objects (and with Main that can be easily prevented), it has proven workable in practice so it's not a significant factor of consideration here. Main can simply be include in Object to achieve that effect.
+This would provide all the facilities required of the toplevel without all the proxy troubles. Also, while I'm not so convinced of the merits of every toplevel method becoming a private method of all objects (and with Main that can be easily prevented), it has proven workable in practice so it's not a significant factor of consideration here. Main can simply be included in Object to achieve that effect.
 
 ```ruby
 class Object
   include Main
 end
 ```
 
-But when we do that it becomes very clear what Main appears to be: Kernel. That strikes me as esspecially interesting. Then again, there may be good reasons to keep the Kernel as a separate module, in which case we'd just have a class hierachy:
+But when we do that it becomes very clear what Main appears to be: Kernel. That strikes me as especially interesting. Then again, there may be good reasons to keep the Kernel as a separate module, in which case we'd just have a class hierarchy:
 
 ```ruby
 Object.ancestors