From: dblack@...
Date: 2007-06-26T06:32:59+09:00
Subject: Re: Error in ancestor?

Hi --

On Tue, 26 Jun 2007, Rick DeNatale wrote:

> 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.

I'm thinking of the birth of objects on the Ruby side, though:

   c = Class.new

or

   class C

where (as far as I can determine) there's no way to get access to the
(thing we're for the moment calling :-) metaclass before the class
itself.

> 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.

I like visibility, and I like non-special-caseness; it's a revelation
to a lot of people to learn, for example, that class methods are
singleton methods on Class objects.  On the other hand, as much as I
would like it not to be, it's a special case at some level.

I guess the ideal terminology would encompass both the similarities
and the differences.  Clearly there's some very strong identity
between:

   class << C   # where C is a class

and

   class << some_non_class_object

and it makes sense to treat them at least up to a point as the same
thing.  (Or *past* a point?)  But I don't have the perfect terminology
to hand by any means.


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)