On 24 Aug 2005, at 08:53, David Brady wrote:

> Guys,
>
> I don't understand.  This is a feature of agile languages, not a  
> defect.  Leaving the door open for chainsaw-wielding maniacs also  
> leaves the door open for gifted neurosurgeons.
>
> I understand your frustration, and I feel your pain.  But I am left  
> with a critical question:
>
> Where were your unit tests?

I don't understand why I'm supposed to test a standard library I'm  
using.  Usually I read the documentation and expect it to work that  
way, but maybe I'm crazy.

> Admittedly, silence_warnings might not be testable.  You might have  
> to code review that to catch it.  But then again, if *your* unit  
> tests all pass, then silence_warnings shouldn't affect you-- 
> especially if you test the failure cases and assert that warnings  
> were returned.

Right now, silence_warnings is only used in the library's test code,  
but that doesn't mean it won't get abused and start wrapping things  
that *should* give warnings.  (Of course, the library in question is  
so completely -w unsafe, the warnings would be lost in a pages of  
noise.)

The way silence_warnings is used is the real problem.  Ruby already  
has a perfectly good method of doing exactly what silence_warnings  
was written to accomplish (two of them, in fact!).

> Logger integrity, however, should be straightforward.

You would think that, until one library decides to go ahead and break  
it.  The library where these were found has at least a handful of  
places where you can find questionable software engineering practices.

> I don't mean to come across like a heartless jerk or a TDD zealot.   
> I am neither.  I am just looking at your pain and thinking, "why  
> does this have to hurt?"

It hurts because the library decided to us in the middle of a  
minefield without a map.

-- 
Eric Hodel - drbrain / segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04