From: Claus Spitzer Date: 2004-05-20T02:57:50+09:00 Subject: Re: How to duck type? - the psychology of static typing in Ruby 8< ----- snip ----- > As good as a code coverage tool is, it still only works with running > code. It will tell you what areas aren't being used regularly, but then > you have to find a way to check them. > > What I'm looking for is more what another poster mentioned: > > > A better example is that perl does exactly what you were asking for > > otherwise (behavior when -c and -v are both supplied to the ruby > > interpreter): > > > > jenova ~ % cat -n what.pl > > 1 $num = 3; > > 2 $num += 2; > > 3 if ($numb != 5) { > > 4 print "Foo!!\n"; > > 5 } > > jenova ~ % perl -cw what.pl > > Name "main::numb" used only once: possible typo at what.pl line 3. > > what.pl syntax OK > > At no point does it try to run the code, but it still finds that > potential trouble spot. > > I think unit tests are great, so are code coverage tools, as are > profilers and debuggers... but I still see a need for 'typo catchers'. > > Ben > > I'm just speculating here, but could perhaps a reason why it is difficult to implement such a thing be that because, unlike Perl, Ruby implements reflection [see "Concepts and Experiments in Computational Reflection", Pattie Maes, 1997] at least to some degree? As aforementioned this is just speculation of mine and not based on anything but my understanding of Ruby's nature; perhaps Matz can enlighten us on that. But if reflection _is_ implemented then complete typo checking could be near impossible because the code would be able to change itself during execution (including creating new objects). Keep in mind though that I said _complete_ typo checking - checking of object names previous to compilation shouldn't be that difficult, albeit not complete. Anyway, that's just my $0.02. It could turn out that I'm completely wrong. Feel free to point out any fallacy in the above line of reason - I've never refused an opportunity to correct my knowledge as of yet. Cheers! -Claus