Hi --

On Wed, 20 Apr 2005, Chris Pine wrote:

>>> One possible explanation for this discrepancy is that the diagram is wrong.
>>> Another is that instance_of? doesn't take into account singleton classes.
>>>
>>> I guess it's the second one :).
>>
>> instance_of? tells you (accurately, definitively) whether or not
>> something is an instance of something.  Obviously you can draw a
>> diagram that posits any relationship you wish.
>
> Then what do the sideways arrows in the 'ri Class' documentation mean?
> Carlos didn't draw that diagram, and he isn't making that up.
> Clearly, there's a meaningful relationship there.

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.

> See again the 'klass' arrow on page 384 (Figure 24.3) of the Pickaxe2.
>
> If "instance_of? tells you (accurately, definitively) whether or not
> something is an instance of something", then it sounds like you
> defining the instance of something to be "that which is returned by
> instance_of?".

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

> It seems to me that there are two very different relationships here:
> what I will call "instance" (though David might not like how I will
> use it) and what I will call "superclass".  These are the arrows used
> both in 'ri Class' and in the pickaxe, and I think these are the
> meaningful relationships.  (Usually, the relationship one-to-many
> relationship of 'kind_of?' is what we want, but that is built out of
> one "instance" relationship, and zero-or-more "superclass"
> relationships.)

The arrows in ri Class are inheritance are described as representing
inheritance, not instance-ness.  (And all these relationships are
meaningful -- we're just talking terminology :-)

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

? :-)

> that object's immediate "papa" has changed.

And that's definitely a significant operation.  It just doesn't seem
to entail a change at the "what this is an instance of" level.  I can
imagine a definition or adaptation of "instance" that did refer to
both, 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".

To put it another way: in describing what happens when a singleton
class is created, it seems to me to be problematic to choose a term
which, immediately, Ruby is going to tell you is wrong.  Certainly
there should be terminology for all of this (or perhaps the problem is
there's too much :-) and it's all important.  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.

Whoops, I deleted the thing where you said that you would argue that
an object's class changes when its singleton class is created....
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.  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 :-)


David

-- 
David A. Black
dblack / wobblini.net