Issue #19573 has been updated by 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?

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. 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? ---------------------------------------- Feature #19573: Add Class#singleton_inherited https://bugs.ruby-lang.org/issues/19573#change-102640 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- 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. ```ruby 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`. -- https://bugs.ruby-lang.org/

Issue #19573 has been updated by jeremyevans0 (Jeremy Evans). mame (Yusuke Endoh) wrote in #note-2:

@jeremyevans0 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. ---------------------------------------- Feature #19573: Add Class#singleton_inherited https://bugs.ruby-lang.org/issues/19573#change-102729 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- 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. ```ruby 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`. -- https://bugs.ruby-lang.org/