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

Hi --

On Thu, 8 Jul 2004, Jeff Mitchell wrote:

> --- "David A. Black" <dblack@wobblini.net> wrote:
> > On Thu, 8 Jul 2004, Charles Comstock wrote:
> > > Sorry perhaps I didn't word my question well.  I meant when does it cause a
> > > problem for a class x to match itself?  What code fails if A === A results in
> > > true?  Why would you ever want to match the descendents and instances of A but
> > > not match A itself.
> > 
> > It doesn't match the descendants of A, but rather instances of the
> > descendants of A:
> > [...]
> 
> He is asking why isn't === defined as

Right, but the question becomes less relevant given that the method
doesn't actually match the descendants of A -- so the answer is: you
wouldn't, and it doesn't :-)

> class Module
>    def ===(obj)
>       obj.is_a?(self) or obj == self
>    end
> end
> 
> or maybe
> 
> class Module
>    def ===(obj)
>       obj.is_a?(self) or obj.ancestors.include?(self)
>    end
> end

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.  


David

-- 
David A. Black
dblack@wobblini.net