From: Ralph Shnelvar Date: 2010-08-23T08:52:11+09:00 Subject: Re: case and class ------------81C5CA757D7E8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit David, Sunday, August 22, 2010, 5:15:16 PM, you wrote: DAB> Hi -- DAB> On Sat, 21 Aug 2010, Ralph Shnelvar wrote: >> I can, reluctantly, see the use of === in an if statement. >> To me, >> case x >> when XXX then ... >> end >> would be MUCH clearer as >> case x.class >> when XXX.arrayOfDecendants >> end >> Of course, the code above is illegal ... but would have been clearer ... at least to me. 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> => # DAB> >> case c DAB> >> when M; 1 DAB> >> end DAB> => 1 DAB> If you want to know whether a given class has a certain ancestor, you DAB> can do that too, but with a different technique: DAB> if C.ancestors.include?(B) DAB> etc. DAB> In general, the === mechanism is advantageous because it means you DAB> always know what's going on in a case statement, and because it gives DAB> you control over how your own objects behave in case statements. Responding to this last paragraph ... If I were the language designer I'd have two "cases" (1) case== which would use the normal == semantics (2) case=== which would use the === semantics. Again ... at least this would be clearer to ME. DAB> David Maybe when I understand Ruby a lot better than I do that the explanation you provided will make more sense. ------------81C5CA757D7E8--