From: Chris Pine <nemo@...>
Date: 2002-12-12T15:57:34+09:00
Subject: Re: do I really not understand inheritance??

Hmm....  I see what you're saying, I think.  I was going to give you a
counter-example, but I can't because you can't subclass Class.  This, of
course, begs the question:  Why can't you subclass Class?

Here's why I ask:

Let's say you have a class 'A', and an instance 'a' of 'A'.  So, at this
point, a's klass pointer points to A, A's klass pointer points to Class, and
A's super pointer points to Object.  (For my diagrams, let's say klass
pointers are vertical and super pointers are horizontal.)

            Class
              ^
              |
              |
Object  <---  A
              ^
              |
              |
              a


I'm saying that I think a singleton class of a (which I will call A:a,
because it sort of sits between A and a, and because it is sort of the "new
A" for a) should be a regular class which subclasses A, like this:

               Class
              ^      ^
              |      |
              |      |
Object  <---  A <-- A:a
                     ^
                     |
                     |
                     a


(The klass pointers of A and A:a are pointing at Class; they are both
classes.)  So what are the ramifications of this idea for classes?  More
specifically, what happens if I define a class method of A, creating a
singleton class (which I will call Class:A)?  Well, it seems like it should
work like this:

Class   <---  Class:A
              ^      ^
              |      |
              |      |
Object  <---  A <-- A:a
                     ^
                     |
                     |
                     a

(Now the klass pointers of A and A:a are pointing to Class:A.  Also, I
assumed that we made Class:A *before* A:a, but that's almost always the
case; most classes have singleton classes already, if only to handle the
method 'new'.)  Currently, this is impossible, though, because you can't
subclass Class; my idea of Class:A is that it is a subclass of Class.

To me, this all seems much more natural.  We didn't create any sort of
bizarre "hidden" class (and no matter how cool you may find the
functionality currently provided by singleton classes, they themselves are
totally exceptional and bizarre) to make everything work.

So what am I missing?  Why can't you subclass Class?  Was this for the sake
of implementation?  I can't imagine it's just so we can have singleton
classes.  (That would be like having your tooth drilled just so you can have
a filling... if there's no cavity (implementation problem), couldn't we just
skip the whole thing?)


----- Original Message -----
From: <dblack@candle.superlink.net>

[snip]

Mind you, I don't want to discourage the loosening of the notion of an
object's "class".  Imagine what would happen to the idea of testing
for type:

  case thing
  when String ...
  when Array  ...
  when Thingy ...

if adding a singleton method to thing changed its class!
----------------------------

Well, I thought it was understood that testing for type is a Bad Thing.  If
anything, one should test for kind_of?, which is actually what Module#===
does anyway (which is a Good Thing).  So the above code would work just
fine.  Adding a singleton method might change an object's class, but it
would still be a kind_of? its original class.


----------------------------
To get all of them you'd want to traverse both the singleton class and
the non-singleton [do we have a better word than that?] class:

  class Object
    # This doesn't save any typing in this example, but
    # it can come in handy in the long run :-)
    def singleton_class
      class << self; self; end
    end

    def all_ancestors
      (singleton_class.ancestors + self.class.ancestors).uniq
    end
  end

  p ENV.all_ancestors   # [Enumerable, Object, Kernel]

----------------------------

Are you sure?  I don't think you need to even look at self.class.ancestors;
everything you need is in singleton_class.ancestors (suggesting what I am
advocating above... it really seems like Ruby only went half-way with this
one).  In any case, regarding the above, I was asking if there was a way to
get the singleton class *without* creating one in the process (as you have
done), in which you get the singleton class if it already exists, or nil if
it doesn't.  But, it probably isn't possible.

Thank you MUCH for your very thoughtful and thought-provoking response!

Chris