From: "David A. Black" <dblack@...>
Date: 2004-07-08T08:35:25+09:00
Subject: Re: Class#=== has interesting results

Hi --

On Thu, 8 Jul 2004, Charles Comstock wrote:

> > 
> > I think you mean obj.class.ancestors, in which case is_a? should take
> > care of it -- which means that your second definition is actually how
> > the method works, I believe.
> > 
> > As for the first, and Charles's question about why it doesn't work
> > that way: look again at my earlier example:
> > 
> >   case s
> >     when String ...
> > 
> > With the "is_a? or ==" implementation, this 'when' clause could mean
> > either that s is String (the Class object) or that s is "Hi, how are
> > you?" (a String object).  Knowing that something is either String or a
> > string, but not knowing which, isn't very valuable; it's hard to imagine
> > a case where you would act on that kind of information.  
> > 
> 
> I don't think you would generally pass either an instance of string or 
> String to a case statement like this, so it shouldn't generally matter. 

The problem is more fundamental, though: you would be unable to know
why "when String" had returned true, so you'd have to test it further
-- so the case statement would have done you no good.  If you're sure
in advance, then having the double behavior isn't necessary; and if
you're not sure, then the double behavior makes the method useless.

>   However I think I found a better logical explanation as to why this is 
> false.
> 
> String is a constant name that represents a String, however constants 
> names that represent String are not strings themselves, so therefor it 
> doesn't match.  Thus if s holds String it is holding a reference to a 
> constant name and not to a String, so it doesn't match.
>
> Which makes sense, and I can accept that logic.  Sorry I guess I wasn't 
> making myself clear in what I was asking and so alot of your responses 
> were to the question of what Module#=== is useful for, as opposed to 
> answering my question which was "why doesn't A === A return true". 

You were clear; my point was that if A === A is true, and A === A.new
is also true, the === method isn't giving you any useful information,
which in turn is a reason for its not being designed that way.  As for
the design choice between the two, my impression has always been that
Matz felt the #is_a? one would be more likely to be useful than the
#== one.  

> Which has now been answered.
> 
> So now I revise my question:
> 
> Given that A === A logically returns false, is there a good way in a 
> case statement to check if these things are the same by some other 
> property?      For instance a = A; a.id === A.id returns true, but is 
> that a logical way to test this?  Or is there another way?

id should achieve what you want, or maybe you could use an if
statement instead of a case statment.


David

-- 
David A. Black
dblack@wobblini.net