From: "David A. Black" Date: 2009-09-06T20:56:52+09:00 Subject: Re: Type checking function parameters Hi -- On Sun, 6 Sep 2009, spiralofhope wrote: > Along the lines of this thread.. > > I'm rough around the edges, so I'll just use some general language. > > I have a habit of building my code like bunches of little black boxes. > Each box accepts a certain kind of input and returns a certain kind > of output. > > For each of the boxes, I create a sort of gateway that ensures that a > box only receives its expected input, and it intelligently reports an > error if that's not the case. > > Should I be loosening my grip and removing some or perhaps all of > those gateways, just like the explanations for duck typing? Probably. For one thing, in Ruby, it's very, very difficult to verify whether or not an argument is going to satify the needs of the method. You can check whether something is of class String, for example, but then you need to wonder why a StringIO object, or another object whose type can handle what you want it to do, won't also work. By "type", I do not mean "class". In Ruby, type and class are not the same. Every object is an instance of a class, but the type of an object is the sum of what the object is capable of at a given time. That's a very elastic and kind of inductive thing, which is why the notion of type is actually kind of moot in Ruby. 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); 2. you stop yourself from creating more flexible, agile (small 'a' :-) program design. David -- David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com Ruby/Rails training, mentoring, consulting, code-review Latest book: The Well-Grounded Rubyist (http://www.manning.com/black2) September Ruby training in NJ has been POSTPONED. Details to follow.