Project

General

Profile

Feature #15627

Appearance of custom singleton classes

Added by sawa (Tsuyoshi Sawada) over 1 year ago. Updated 18 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:91640]

Description

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

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.

Updated by Eregon (Benoit Daloze) over 1 year ago

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.

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

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”).

Updated by mame (Yusuke Endoh) over 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.)

Updated by Hanmac (Hans Mackowiak) over 1 year ago

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

Updated by mame (Yusuke Endoh) over 1 year ago

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.

#6

Updated by jeremyevans0 (Jeremy Evans) 9 months ago

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

Updated by ParadoxV5 (𝕻𝔞𝔯𝔞𝔡𝔬𝔵Ⅴ⓹ ⛥) 18 days ago

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__))

Also available in: Atom PDF