From: Charles Comstock <cc1@...>
Date: 2004-07-08T08:07:35+09:00
Subject: Re: Class#=== has interesting results

> 
> 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. 
  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". 
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?

   Charles Comstock