I’ve been thinking about singleton methods some more. The current
implementation
tucks away singleton methods in a class object. Method lookup is
subsequently
altered to consult the singleton class of the receiver (if it exists).
Is there a particular reason why a class object is used for this purpose
rather than a module?
My motivation for this question was the observation that the
semantics of a
singleton class seem closer to a module than a class:
-
method lookup is altered like a module mixin, but
the inheritance structure is not modified nor is the change
visible via ancestors (which makes sense because ancestors is
only defined for a class not for an object but which suggests that
ancestors could be defined in Kernel and return an array which
includes the singleton classes for the object) -
if B is a subclass of A then method lookup for B.x consults
the singleton class of B and the singleton class of A as if
the singleton class of B included the singleton class of A
even though the singleton class of B is not a subclass of the
singleton class of A. (i.e., method lookup is like included modules
not like subclasses) -
the singleton class doesn’t have an instance (in the sense that
there is
no object x such that x.class references the singleton class).
Calling
new on a singleton class generates an exception. This is like a
module. -
singleton classes don’t really participate in the inheritance
hierarchy
or perhaps it is more accurate to say that they participate in an
extremely
constrained way (superclass returns the singleton class of Class,
yet I
can’t come up with an example that would cause a method to be
looked up
in the singleton class of Class other than a direct message send
to Class).
I think I’ve got the details correct but I welcome any corrections/
clarifications.
Gary W.