Well, I just happened to be mucking about with that sort of thing and
I think you might have an issue where if they were modules, you'd have
to deal with being able to call foo.metaclass.extend_object on another
object, which then makes it pretty trivial to have it interacting in
the inheritance hierarchy.

Incidentally, does anyone know of a way to do that sort of object
prototyping thing under 1.8.4?  It apparently used to be possible in
1.8.2

On 2/2/06, gwtmp01 / mac.com <gwtmp01 / mac.com> wrote:
> 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 Wright
>
>


--
-Dan Nugent