> I'm uneasy with the explanation that "instance_of? doesn't take into
> account singleton classes", because, as I read it, it seemed to
> suggest that what instance_of? returns is irrelevant to the question
> of whether or not something is an instance of something else.  I'd
> rather trust the method; otherwise, I don't know where to start or
> stop second-guessing the meta-information that Ruby gives me.

Yeah, I can definitely see your point.  My view is that, in actual,
practical code, don't use 'class' or 'instance_of?' at all, use
'kind_of?'.  That's almost certainly what you want, and it does take
into account singleton classes and modules (another aspect of all of
this we are leaving out).  Though, if you can avoid 'kind_of?' and
just use your duck typing and unit testing, of course that's the best
thing.  :)

But if you are playing around with meta-info in Ruby, it kind of seems
like you have to distrust 'class' and 'instance_of' for these reasons.
 Or at least make it clear that you mean "birth class" and not "first
class in the list of things this object is a 'kind_of?'"  But who
wants to give those sorts of qualifiers all over?  :)


> instance_of? returns true or false; I'm just taking that literally.

Well, it seems like some interpretation is perhaps called for.  As has
been noted, 'Object.superclass' return 'nil'... and we don't want to
take that too literally!  <chuckle, chuckle>

<chuckle>

(I'm sorry, but that really cracked me up...)

<chuckle>

Oh, boy.  If anyone else here thinks I'm half as funny as *I* think I
am, then... they... must... think I'm pretty funny.  <ahem>


> The arrows in ri Class are inheritance are described as representing
> inheritance, not instance-ness.

Actually, though they are not listed as such, the sideways arrows do
not.  Classes cannot have two superclasses, and a class's relationship
to it's superclass is really nothing like it's relationship to it's
singleton class (which is much more line an instance-ness
relationship).

For my OSCON talk on the Ruby Object Model (back in 2003), I used
different colored arrows for that particular picture.  That really
helps a lot.


> (And all these relationships are
> meaningful -- we're just talking terminology :-)

Very true.


> > When you create a singleton class for an object, you are changing the
> > 'klass' pointer and, as I see it, changing which class it is an
> > instance of.  What is returned by "instance_of?" does not change (and
> > I'm complaining about that, mind you; I'm fine with how it works), but
>    ^^^^^^^^^^^^^^^

NOT complaining!  NOT AT ALL complaining!  Yikes...


> but it appears that Matz's choice is to have the "instance of"
> relationship apply only to the relationship between an object and its
> "birth class".

Yes, it does appear that way.  I think it's a mistake how he has tried
to hide this stuff "under the rug" as it feels to me.  On the other
hand, I'd have made far more mistakes in making a language, and in
practice this stuff never comes up at all.

If I were to do some serious metaclass hackery, I would certainly not
be using 'class' and 'instance_of?' anywhere.  I'd use why's tools. 
If I were just trying to explain how the Ruby object model works
(something I have thought a fair bit about), I would similarly avoid
them, instead talking about 'kind_of?'.  And in all other cases, duck
typing is the way to go.

Given all of that, 'class' and 'instance_of?' don't seem like very
useful methods as they work now.


> I just don't want to
> create a terminological inconsistency that then has to be sort of
> re-explained or "asterisked" every time it comes up.

Amen!  Although, I feel like this is already the case...  :)

"Well, Ruby does say that the class is String, and we know that when
Ruby checks for methods, it starts with the class, then moves up the
inheritance chain... but really, it starts with the singleton class,
then up to any included modules in reverse order that they were
included, *then* up to String and so on..."

I feel like to really explain the topic, you kind of have to say all that.


> This is why I want Kernel#singleton_class (or Object, or wherever) --
> because it's not an either-or choice.  They both exist, and they
> should both be (easily) referable to.

Agreed.


> I would actually be happy with
> #class becoming #birth_class, and being paired with #singleton_class
> (or #own_class), but one thing at a time :-)

Yeah... I'm not sure.  I'm fine with it as it is, I guess because it
looks easy to a beginner (which is important for a tutorial writer
like me).  It is an over-simplification, but on the surface it makes
sense.  Then, when you dig down, you learn that 'class' is, in
whatever sense, not telling you the "whole" truth.  That's fine, too,
because at that point you are fairly advanced, and can handle it.

I think it's great that you can do a lot of Ruby *without* having to
know this stuff.

Chris