Feature #19573: Add Class#singleton_inherited

• Status: Rejected
• Assignee: -
• Target version: -

[jeremyevans0 (Jeremy Evans)]

This would be similar to Class#inherited, but would be called with singleton classes of instances instead of subclasses. This could be used to warn or raise on singleton class creation, or modify the instance to change behavior, such as allow optimizations when a singleton class does not exist, but allow fallbacks if it does exist.

c = Class.new do
  def self.inherited(subclass)
    p :inherited
  end
  def self.singleton_inherited(singleton_class)
    # could use singleton_class.attached_object for modifying related object
    p :singleton_inherited
  end
end

Class.new(c)
# prints :inherited

c.new.singleton_class
# prints :singleton_inherited

This could potentially be an instance method (e.g. Kernel#singleton_class_created or BasicObject#singleton_class_created) instead of a class method. However, that would not grant any additional flexibility, since per-object behavior first requires creation of a singleton class.

If this is accepted, should the method be called for singleton classes created by Kernel#clone if the receiver has a singleton class? I think it should, as Class#inherited is called for Class#clone.

[sawa (Tsuyoshi Sawada)]

I have a little concern about the method name. self.inherited(subclass) reads as

self is inherited by subclass.

Will an analogy work such that self.singleton_inherited(s_class) reads something like:

self is inherited by s_class {in the sense of/from the point of view of/etc.} singleton or
self is singleton-ly inherited by s_class?

I am not sure. When you have a sequence "foo inherited," it is natural to interpret "foo" as the direct object of "inherit" (in an active sentence). This works fine in case of self.inherited(subclass): "self is inherited by subclass," or "subclass inherits self".

With self.singleton_inherited(s_class), we still want to say that self is the direct object of "inherit", but "singleton" is stuck in between them, which makes it potentially unclear what the direct object is. Perhaps, it is more tempting to read it as

singleton is inherited by self, or self inherits singleton,

contrary to the intention, unless it is clear that the "singleton" here is meant to be some kind of an adverbial expression along the lines of "{in the sense of/from the point of view of} singleton." I am not sure if that is the case. It may be a good method name, it may be not. I am not sure. Maybe self.inherited_by_singleton_class(s_class) would be more clear.

On other hand, would it work if Class#inherited takes a keyword argument: foo.inherited(subclass, singleton: true), or even go further to let Class#inherited be triggered also on singleton class creation? Given that we have Class#singleton_class?, it is relatively easy to separate the cases if necessary.

[mame (Yusuke Endoh)]

@jeremyevans0 (Jeremy Evans) Could you explain the use case?

This could be used to warn or raise on singleton class creation

Why do you want to warn such a case? (To avoid some performance degeneration?)

or modify the instance to change behavior, such as allow optimizations when a singleton class does not exist, but allow fallbacks if it does exist.

AFAIK, it is not visible for a Ruby programmer if a singleton class is "generated" or not. What optimization do you have in mind?

My understanding of the Ruby object model is that every object has a singleton class from the beginning. class << obj just retrieves it.
Because a naive implementation that actually makes every object have a singleton class will be slow, it is lazily generated as needed. But I think that it is just a kind of internal optimization, which should be invisible to a Ruby programmer.

[jeremyevans0 (Jeremy Evans)]

mame (Yusuke Endoh) wrote in #note-2:

@jeremyevans0 (Jeremy Evans) Could you explain the use case?

This could be used to warn or raise on singleton class creation

Why do you want to warn such a case? (To avoid some performance degeneration?)

Correct. I recently updated Sequel to avoid singleton classes for datasets, with performance improvements of 20-40% even in simple cases (and potentially more in more complex cases).

The reasons for the improvements:

• Singleton classes on regular objects result in uncached method lookups.

• #clone for objects with singleton classes results in singleton class clones. Sequel uses #clone extensively.

Avoiding the use of singleton classes significantly improved performance in this case. It could potentially improve performance in other cases.

or modify the instance to change behavior, such as allow optimizations when a singleton class does not exist, but allow fallbacks if it does exist.

AFAIK, it is not visible for a Ruby programmer if a singleton class is "generated" or not. What optimization do you have in mind?

In terms of visibility, that used to be true for plain Ruby methods (you could work around using a C-extension). Starting in Ruby 3.2, you can check for visibility in plain Ruby:

public def has_singleton_class?
  ObjectSpace.each_object(Class){|obj| return true if obj.singleton_class? && obj.attached_object.equal?(self)}
  false
end

However, as that uses ObjectSpace.each_object, it is rather slow.

In terms of optimization, the optimization that Sequel uses is that it takes something that previously used clone(freeze: false) and extend(*mods) with something that does Class.new(self.class){include(*mods)}.new(self.db, self.opts). This optimization is broken if the receiver does have a singleton class. For Sequel's case, because all Sequel datasets are frozen by default (and you cannot add a useful singleton class to a frozen object), I was still able to implement the optimization. But other libraries that do not use an always-frozen design would not currently be able to perform a similar optimization safely.

My understanding of the Ruby object model is that every object has a singleton class from the beginning. class << obj just retrieves it.
Because a naive implementation that actually makes every object have a singleton class will be slow, it is lazily generated as needed. But I think that it is just a kind of internal optimization, which should be invisible to a Ruby programmer.

Conceptually, I agree with you. If the performance increase from avoiding singleton classes was not so large, I would not be proposing this. However, considering the extent of the performance increase from optimizations to avoid singleton classes, I think having a hook on singleton class creation is a good idea.

[Eregon (Benoit Daloze)]

• Related to Feature #19538: Performance warnings added

[Eregon (Benoit Daloze)]

Related: https://bugs.ruby-lang.org/issues/19538?next_issue_id=19537&prev_issue_id=19541#note-7

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Rejected