Feature #15627: Appearance of custom singleton classes

• Status: Open
• Assignee: -
• Target version: -

[sawa (Tsuyoshi Sawada)]

When I have a singleton class AClass of an instance a of a custom class A,

class A; end
a = A.new
AClass = a.singleton_class

i) even though the singleton class of nil, false, and true are referred to by their assigned constant names, the singleton class AClass of a is not:

nil.singleton_class #=> NilClass
false.singleton_class #=> FalseClass
true.singleton_class #=> TrueClass
a.singleton_class #=> #<Class:#<A:0x00007fda832a7eb0>>

ii) even though the singleton class of nil, false, and true appear as their class, the singleton class AClass of a does not:

nil.class #=> NilClass
false.class #=> FalseClass
true.class #=> TrueClass
a.class #=> A

This contrast between nil, false, and true on the one hand and a on the other is confusing. I am actually not sure if this is intended behaviour It may be related to

• https://bugs.ruby-lang.org/issues/15608
• https://bugs.ruby-lang.org/issues/14895

I expect AClass to behave the same as with NilClass, FalseClass, and TrueClass. I expect:

a.singleton_class #=> AClass
a.class #=> AClass

If the current behaviour is intended, I would like this to become a feature request.

[Eregon (Benoit Daloze)]

singleton_class and class are different by design.
They are only the same for true, false and nil.

Having the singleton class get named when assigning it to a constant sounds like a possible feature.
Although it doesn't seem common to assign a singleton class to a constant.

[nobu (Nobuyoshi Nakada)]

At first, as no syntax to name a singleton class like ordinary classes/modules, singleton classes cannot have a name.
And name-by-assignment is a “best effort” (or “better than nothing”).

[mame (Yusuke Endoh)]

Rather, it looks a bug that #singleton_class returns a non-singleton class:

p Object.new.singleton_class.singleton_class? #=> true

p true .singleton_class.singleton_class? #=> false
p false.singleton_class.singleton_class? #=> false
p nil  .singleton_class.singleton_class? #=> false

1.singleton_class #=> can't define singleton (TypeError)

It looks reasonable to raise an exception like 1.singleton_class. (But I'm unsure if it is worth enough to break compatibility.)

[Hanmac (Hans Mackowiak)]

@mame (Yusuke Endoh) it is by design that true, false and nil has their class work as singleton class so you can do:

def true.bla
  # something
end

[mame (Yusuke Endoh)]

Wow.

def true.foo; end
p TrueClass.instance_methods.include?(:foo) #=> true

I didn't know, thanks. I have used Ruby for fifteen years, but Ruby still brings fresh surprise to me.

[jeremyevans0 (Jeremy Evans)]

• Tracker changed from Bug to Feature
• Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN)

That being said,

Why does TrueClass, FalseClass and NilClass classes in Object instead of just singleton_class of true, false and nil repectively?

If it’s for backwards compatibility, remember that with major updates (e.g. Ruby 3.0) we don’t need to guarantee backward-compatibility (Ruby 3’s being changes to how keyword arguments are parsed).

(true, false and nil are more like pseudo-constants compared to other pseudo-variables (self, __FILE__, __LINE__))