From: "David A. Black" <dblack@...>
Date: 2010-08-24T07:11:31+09:00
Subject: Re: case and class

Hi --

On Mon, 23 Aug 2010, Ralph Shnelvar wrote:

> DAB> It doesn't suggest the same functionality, though. This:
>
> DAB>    case obj
> DAB>    when XXX
>
> DAB> runs XXX === obj (as per Colin's explanation), and that examines whether
> DAB> or not XXX is in the method look-up path of obj. This may or may not
> DAB> have anything to do with obj's class -- for example:
>
> DAB>    >> class C; end
> DAB>    => nil
> DAB>    >> module M; end
> DAB>    => nil
> DAB>    >> c = C.new.extend(M)
> DAB>    => #<C:0x14cd14>
> DAB>    >> case c
> DAB>    >> when M; 1
> DAB>    >> end
> DAB>    => 1
>
> Maybe when I understand Ruby a lot better than I do that the
> explanation you provided will make more sense.

Here's some annotation:

Every object has a lookup path, consisting of classes and modules in a
particular order, which it traverses when it's trying to resolve a
method name. If you extend an object with a module (see above), you
insert that module into the lookup path of the object. Any module or
class that's in the lookup path of an object (including, but not limited
to, the object's class and modules included in that class) will match
the object for purposes of case equality.

So what I was getting at in my example is that knowing an object's
class, and even that class's ancestors, doesn't tell you everything that
Module#=== tells you. In the example, the "1" shows that M === c, even
though c's class does not include M.


David

-- 
David A. Black, Senior Developer, Cyrus Innovation Inc.

   The                   Ruby training with Black/Brown/McAnally
   Compleat              Philadelphia, PA, October 1-2, 2010
   Rubyist               http://www.compleatrubyist.com