On Oct 22, 2007, at 3:52 PM, Rick DeNatale wrote: > On 10/22/07, Sean O'Halpin <sean.ohalpin / gmail.com> wrote: >> On 10/22/07, Sean O'Halpin <sean.ohalpin / gmail.com> wrote: >>> >>> >>> if donald === CanQuack >> >> >> should be >> >> if CanQuack === donald >> > > Which is functionally equivalent to > donald.is_a? CanQuack > > it might read better, but I still maintain that checking with is_a? is > still weaker than most folks assume. > > -- > Rick DeNatale > as i was mentioning to david, my experience is that it just depends: if you are writing something like case conn when TCPSocket when UDPSocket end then is_a? is probably pretty strong - as strong as it possible in ruby since we can always def class() Lie end nevertheless my general rule tends to be along the lines of using class/module/is_a? type checks for built-ins since people who muck that too much get what they deserve if those classes stop working, using 'respond_to?' to keep apis flexible (require as little as possible from client code), and using something like Object.instance_method(:instance-_eval).bind(object).call(*a, &b) when trying to write robust meta-programming type stuff like adding methods to object since i want to *force* compliance iff possible. this whole thread is pretty interesting though - it shows how flexible we as programmers have to be to accommodate the openness ruby. i think some people would point out this as a weakness because we have to think and talk about these things but, in reality, it's only an issue in pretty sticky situations - situations i personally don't attempt to get myself in using less powerful languages. the language choice does indeed change the way we think about problems and, as such, cannot truly be equivalent for a given task when compared to other languages - contrary to what turing would tell us ;-) cheers. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama