Feature #19573
closedAdd Class#singleton_inherited
Description
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
.
Updated by sawa (Tsuyoshi Sawada) over 1 year ago
I have a little concern about the method name. self.inherited(subclass)
reads as
self
is inherited bysubclass
.
Will an analogy work such that self.singleton_inherited(s_class)
reads something like:
self
is inherited bys_class
{in the sense of/from the point of view of/etc.} singleton or
self
is singleton-ly inherited bys_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
, orself
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.
Updated by mame (Yusuke Endoh) over 1 year ago
@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.
Updated by jeremyevans0 (Jeremy Evans) over 1 year ago
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.
Updated by Eregon (Benoit Daloze) over 1 year ago
- Related to Feature #19538: Performance warnings added
Updated by jeremyevans0 (Jeremy Evans) over 1 year ago
- Status changed from Open to Rejected