From: Eleanor McHugh <eleanor@...>
Date: 2009-09-06T22:58:31+09:00
Subject: Re: Type checking function parameters

On 6 Sep 2009, at 12:56, David A. Black wrote:
> Of course you can get a certain amount of mileage by testing the class
> of an object and assuming that if it's of a certain class, it must
> behave a certain way. But by doing so, you create two problems:
>
>  1. it doesn't really work (because class is not the same as type);

Indeed the fact that both classes and objects are open and can have  
methods added, removed or replaced at any point during runtime  
execution means that even if a method checks to ensure that one of its  
parameters is for example a String object, that object may well not  
have the full complement of methods defined by the String class at the  
time code seeks to manipulate it and hence could still raise a  
MethodMissing exception.

Locking down object identity is therefore a cumbersome approach to  
type safety that sacrifices much of the flexibility that makes Ruby a  
pleasure to work with, but in those rare cases where it might seem  
desirable good practice is to filter based upon responds_to not about  
Class identity. In general though code will be more robust if the  
emphasis is placed on good exception handling and testing rather than  
type checking.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason