David A. Black schrieb:

>
> Also, I don't see any harm or danger here.  I suppose one could
> accidentally write a loop that kept creating singleton classes, but
> one could also write a loop that kept creating *non*-singleton classes
> -- or arrays, or hashes, or MyClass objects, and so on.

At least you can print any self referential (looping) object involving the
standard  container classes, Hash, Arrays. Structs and Sets- however

---
class O
end

CrashChild =  class << O; self end.dup

Crash = class << CrashChild
  superclass
end

Crash.inspect
---

results in a system stack overflow (for the "stock 1.8.2 windows
installer" ruby).  This probably has to do with the fact that the
superclass of a normal "singleton singleton class" of a class,  is
necessarily equal to

Klass = class << Class; self end # singleton class of class Class, e.g.
---
class O
end

nocrash = class << (class << O; self end)
  superclass
end

Klass = class << Class; self end

p (nocrash == Klass) # true
---

The core problem is  (I assume because of efficiency reasons), that Matz
took "a little short cut" of not creating the natural chain of "higher 
order"
singleton classes, and cheated by declaring the superclass of any
"higher order" singleton class to be Klass.

Instead of going to the trouble of implementing an ad hoc "higher order
singleton class scheme" (b.t.w. - Ruby had a completely different higher
order singleton class scheme in past)  it might  have been wiser,
well at least less work, of preventing the creation of   "higher order"
singleton classes in the first place.

/Christoph