Appearance of custom singleton classes
When I have a singleton class
AClass of an instance
a of a custom class
class A; end a = A.new AClass = a.singleton_class
i) even though the singleton class of
true are referred to by their assigned constant names, the singleton class
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
true appear as their class, the singleton class
a does not:
nil.class #=> NilClass false.class #=> FalseClass true.class #=> TrueClass a.class #=> A
This contrast between
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
AClass to behave the same as with
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.
Updated by Eregon (Benoit Daloze) over 1 year ago
class are different by design.
They are only the same for
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.
Updated by mame (Yusuke Endoh) about 1 year ago
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.)