On 06/25/2014 04:53 AM, Sylvain J. wrote:
This is a bit my problem as well. Maybe there is a need to be able to
turn some warnings on or off depending on the application (as most
compilers allow these days).
I wondered what it would be like if Ruby had something like C++ #pragma
directives to enable/disable specific warnings. I imagine library
writer A suppressing one warning, and library writer B suppressing
another. Now I use library A and B, and now get two warnings suppressed
for my code, warnings that I wanted to see. This kind of effect makes
me think that, to be of any use, a #pragma-like ability would have to be
lexically scoped (“this file has these pragmas”). But that just seems
ugly. Imagine every file in some library having this block of pragmas
at the top. Every file. So that doesn’t seem like a win.
I think the best approach is to not rely upon “-w” at all, but use a
lint-like tool. I think there are some of these out there for Ruby.
You pick the lint you like, you configure its warnings to your liking,
and you run it. Since lint-like tools are not semantically scoped, but
file-scoped, you don’t have to worry about your lint tool bothering you
with warnings about some library that your program is using. You can
put it in your gem’s rakefile, or in a git commit hook. This, I think,
is the winning approach. Do not burden each Ruby implementation with
knowledge of policies and opinions which are (1) not universal, and (2)
subject to change as personal and community standards evolve over time.
Instead, decentralize warnings, putting them in separate tools.