From: dblack@...
Date: 2007-06-27T07:35:50+09:00
Subject: Re: Error in ancestor?

Hi --

On Wed, 27 Jun 2007, Rick DeNatale wrote:

> On 6/26/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>
>> The thing is, there's one big difference that's not just a matter of
>> implementation: singleton classes of Class objects are the only ones
>> that can actually be called by more than one object (the class, plus
>> its descendants).  So that calls into question the appropriateness of
>> "singleton" as a way of describing them.  I'm not a fan of "metaclass"
>> -- as Jim Weirich (if I recall correctly) said, the only real
>> metaclass in Ruby, i.e., class of classes, is Class.
>
> And from my viewpoint, that last sentence doesn't seem right, true as
> it might be from the current implementation of  Object#class. First of
> all, if the only real metaclass is Class, then what are those
> singleton classes of classes  for?
>
> Each one holds the methods for it's sole instance, and for inheritance
> by it's sub[class?]es.  They are just like classes in that regard.
> Hiding the fact that they exist, and giving the illusion that all
> Class objects are instances only of Class doesn't seem to be natural
> and leads to anomalies like making the concept of protected class
> methods empty since the all classes are considered to have the same
> class.
>
> And since there really is a distinction between the singleton classes
> used for instance behavior, and those sort-of-singleton class thingies
> why not have a term which distinguishes them.  Metaclass is the common
> term for these kinds of objects, and under the covers, ruby singleton
> classes of classes look very much like the metaclasses of Smalltalk or
> CLOS.
>
> I think it would be interesting to think about what would break if the
> following methods were defined/changed.
>
> 1)  Object#singleton  - would return the singleton class of an
> instance, creating it if necessary.
> 2) Module#metaclass - returns the singleton class of the receiver.
> 3) Object#class - returns the 'birth class' of the object.
>     Module "overrides" the implementation of this method to return
>     the metaclass of the receiver.

It still feels to me like this is forking too soon in the road, or
something.  I think of the metaclasses as a superset of the singleton
classes -- basically a singleton class, but with something layered on
top (the inheritance thing).  So having a different name for them
makes sense to me, but "promoting" them to be the response to #class
doesn't.  I fear that this would make:

   c = Class.new

very equivocal: one would have to single it out as the one (I think)
case where SomeClass.new did not result in an object which said that
SomeClass was its class.

My counter-proposal would be:

   1) Object#birth_class
   2) Object#singleton_class
   3) Object#class -- alias for #birth_class (for all objects)
   4) Class#metaclass -- alias for #singleton_class

It seems to me that would allow full exploitation of the similarities,
and full expression of the differences.

(I know I switched it from Module to Class... still pondering that one
:-)


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)