From: John Carter <john.carter@...>
Date: 2007-12-07T07:32:40+09:00
Subject: Re: Worth an RCR? static_type_check, 	polymorphic_type_check,quacks_like

On Thu, 6 Dec 2007, David A. Black wrote:

>> I find this very useful and 'require' it into all code I write. Just
>> helps me mop up those problems that static type checking would have
>> found for me...
>
> Keep in mind, though, that static type checking isn't just some safety
> net that Matz forgot to include in Ruby. The objects are dynamic. You
> can't statically check dynamic objects. You can examine their
> class/module ancestry, but that only tells you their class/module
> ancestry.

> I don't want to recapitulate the thousands (literally, I believe) of
> posts to this and other lists about class/module-checking in Ruby, but
> my two biggest problems with it are:

Yes, yes, yes, I know all the theory, I've read the arguments....and
I'm not suggesting that one make every method call have strictly type
parameter checking.

I don't. I'd say I don't do parameter type checking in 98% of my
methods.

But believe you me, when I hit a bug where I invoke a method that dies
because there is something screwy in an instance variable and the bug
isn't on the backtrace.....

I say, stuff the theory, slap one of those beauties in the constructor
and find the bug instantly.

And then I leave it there to catch the next time I or someone else is
stupid in the same way.

Of course, occasionally, very very rarely, the theory bites me in the
bum and my program dies when it shouldn't, no problem because...

   a) The cause of death and the exact file name and line number to fix
      is right there on the screen in front of me.
   b) It happens during development, not production.

However, given the number of bugs I've caught whilst waiting for such
events, including ones that would have otherwise made it released
version, no amount of theory will convince me not to use this technique.

Please, I'm not saying, Dynamic Ruby Bad strictly typed languages like C++ /
Pascal / ... is Good.

I'm saying this is a really really simple, clean idiom for rapidly
catching a largish class of bugs fairly hard to track down by other means.

ie. These methods aren't about theory, they about a pragmatic
superclean idiom for catching a certain large class of bugs.

ie. Latent defects created by inserting the wrong object into a variable, but
the defect becomes visible at a point where the defective line is not
on the backtrace.

ie. When you have one of these bugs, reach for these methods.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand