From: David King Landrith <dlandrith@...>
Date: 2004-04-03T07:25:59+09:00
Subject: Re: Variable names


On Apr 2, 2004, at 4:28 PM, Mauricio Fern�ndez wrote:

> On Sat, Apr 03, 2004 at 01:30:34AM +0900, Dave Thomas wrote:
>>
>> On Apr 2, 2004, at 10:20, David King Landrith wrote:
>>> Is there any way to access the name of a given variable instance from
>>> within it?  In other words, for any object x, is there C function to
>>> which I can pass self to determine that the program calls it 'x'?
>>
>> You have the file name and line number, and you may even have the file
>> itself in SCRIPT_LINES, so you could cheat and find the name from 
>> that.
>>
>> I'm interested in tis experiment: how often does it catch a problem
>> that you didn't catch though unit testing? Putting that another way:
>> how often do you see these type errors in testing, and how often in
>> production?
>>
>
> This looks like a restricted version of Eivind Eklund's types.rb. 
> Here's
> what the author had to say about it:
>
> "The reason I didn't do any particularly public release of it was
> that I found that adding type checks to ruby programs were worse
> than useless for me - it got in the way of my refactoring, without
> catching many bugs."
>
> See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/84841.

I looked at this before we rolled our own, and decided against using it 
because it seemed overkill.  We just add xxx.should_be(type, symbol) or 
yyy.should_be([type1, type1...], symbol) whenever we want to ensure 
failure due to type mixups.  We make no attempt in our library to try 
to dictate particular combinations parameters, because this seems to me 
to go beyond the point of diminishing returns.  We haven't found that 
it impacts refactoring in the least bit.  Since we are dealing with a 
very large code base, this helps us in two ways:

1. It often keeps harmful things from happening; e.g., 
#<Module::Object:0x40536218> being inserted into a varchar field
2. In many cases, some error would have occurred as the result of the 
wrong type being sent, but forcing it to be an explicit type error 
ensures that (a) the error report accurately reflects the problem, and 
(b) the error is thrown closer to where it occurred.

Best,

Dave

-------------------------------------------------------
David King Landrith
   (w) 617.227.4469x213
   (h) 617.696.7133

Life is tough.  It's even tougher if you're
an idiot.  --John Wayne
-------------------------------------------------------
public key available upon request