On Fri, Feb 23, 2001 at 02:16:34PM -0800, Nathan Wiger wrote:
> Ummm, I'm not too sure about this. There are, actually, backwards
> compatibility concerns. Unless I'm mistaken, warnings go to stderr,
> correct? Meaning that a program which may have lots of "unitialized
> variables" and "variable only used once" warnings in them, *and* which
> rely on outputting useful information to stderr (like "real" warnings
> that the user put in the program) will have that polluted with lots of
> Perl gunk.
Yes, it causes problems between perl 5 and perl 6 if we turn them on
(which p52p6 can take care of) but once they're on, turning them off
doesn't cause much of a problem. Users should be encouraged to still
use -w until we decide if this is a good idea. That decision should
have to be made fairly earily to cause the least problems when we shut
it off.
> This doesn't break code, but it does break the usability and behavior of
> the program. So to do this effectively and transparently p52p6 should
> really stick a "no warnings" in a p5 script to make sure that stderr
> isn't polluted. But then we're back to where we are now....
Yes, p52p6 can do something like C<BEGIN { warnings->unimport unless $^W }>
For Perl 5 programs this does leave us in the same situation as
we are now... but then that's the point of p52p6, isn't it?
> Maybe what we really should be talking about is a way to let site users
> customize what flags are on by default? Just like customizing which
> modules are dynamically vs. statically loaded. I know this issue got
> beaten to death in the language RFC process already, but... if there are
> truly 2 groups with opposing viewpoints, why not add to Configure:
>
> Command-line flags on by default [-T -Mstrict -Mwarnings]:
We already beat this to death with the .perlrc discussion. You'll
break reams of Perl code you probably don't even know you have this
way. For an illustration of the consequences, run: "file /usr/bin/* |
grep perl", take the first result and run it like "perl -Mstrict
/usr/bin/822-date" and watch the fireworks.
For this to work, you'll have to have a /usr/bin/perl configured
normally and a /usr/local/bin/myperl or something configured your way.
Aside from being a colossal waste of disk space, this isn't much
better (probably worse) than just remembering to use -w and C<use
strict>.
It destroys the portability of Perl programs.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
