From: James Edward Gray II <james@...>
Date: 2009-12-22T23:47:21+09:00
Subject: Re: Symbols vs. constants?

On Dec 22, 2009, at 6:59 AM, Rick DeNatale wrote:

> And as for warnings vs. errors.  IMHO, warnings are just that,
> warnings.  They warn of something which might be, and sometimes
> usually will be a problem, but not always.  In most cases, the
> response should be to do whatever need be done to eliminate them, but
> sometimes they are warnings in the sense of "fasten your seatbelt" or
> "slippery when wet."  Redefining a "Constant" can be useful as times.
> And some time warnings, like "parenthesize argument(s) for future
> version", turn out to be non-warnings when the envisioned future
> version (of the Ruby parser) is abandoned.

The great thing about warnings, in my opinion, is that they sometimes find bugs for free.  That only works though, if you notice the warning.  Thus, you need to keep the noise level down so you can see the warning when it is given.  To me, that means resolving all warnings as they come up.

It's interesting to note that what I just described is pretty much standard operating procedure for Perl programmers now.  You'll be hard pressed to find modern Perl literature that doesn't show warnings turned on and avoided in their code.  The same is dramatically less common for us.  This is the one place I feel their culture is superior to ours.

The most important aspect to me is libraries though.  If you write a library that throws warnings, I think we should be able to take your keyboard away.  It's the whole second-hand smoke thing.  You didn't just make a bad choice for you but for me too.

It's also worth noting that it is possible to change a constant without a warning.  In fact, it's possible to do all of Ruby's dynamic magic without warnings, so you certainly can avoid them if you desire.

James Edward Gray II