From: Rick DeNatale <rick.denatale@...>
Date: 2007-06-26T06:24:27+09:00
Subject: Re: Error in ancestor?

On 6/23/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> On Sun, 24 Jun 2007, Rick DeNatale wrote:

> > Were this done, another question arises as to whether e,g, Array.class
> > should still return Class instead of
> > #<Class:Array>.  To me this seems different than the case of hiding a
> > singleton class of an object which is not a Module/Class.
>
> The goal of #singleton_class, though, would be to un-hide the
> singleton class, so #class would be free to report on the "birth
> class" relieved of any responsibility to worry about the singleton.

> I'm not sure about "metaclass" for classes' singleton classes, though
> there's no doubt that the inheritance thing whereby a class can call
> its superclass's singleton methods certainly makes the term
> "singleton" a bit of an imperfect fit....

I think that the differences between singleton classes of classes and
regular singleton classes argue for making Array.class respond with
the singleton class of the class, which I'm going to take the liberty
of calling the metaclass to distinguish between metaclasses and
regular singleton classes, which I'll just call singleton classe's in
the following.

1). As you point out unlike regular singleton classes, metaclasses can
have subclasses.

2). Singleton classes are born on demand when they are needed to hold
a singleton method.  Metaclasses on the other hand are created at the
time of the birth of their sole instance.  In fact I'm almost certain
that if you look at the code flow when a class is created the
metaclass is created first, so in a real sense, the metaclass IS the
birth class of the class.

So I see bringing metaclasses out from behind the curtain, and calling
them metaclasses or something else besides singleton class to
distinguish them from regular singleton classes is useful.

And for those who are fans of access modifiers, I think that this
would allow having protected class methods, since there would be a
visible hierarchy of metaclasses to reason about.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/