[ruby-core:113190] [Ruby master Feature#19573] Add Class#singleton_inherited

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/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/