On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote:
> On Fri, Feb 16, 2001 at 08:41:02PM -0500, [EMAIL PROTECTED] wrote:
> > On Fri, Feb 16, 2001 at 03:28:36PM -0800, Edward Peschko wrote:
> > > Its because '-w' is a global switch.
> >
> > What about the new lexical warnings? "use warnings"?
>
> umm... that's part of what this is all about. People don't have a policy
> towards warnings, which makes '-w' useless.
>
> I *want* a global switch. I want the ability to never have to forget to type
> 'use warnings' in a package and track it down for hour upon hour. Or 'use
> strict'.
Hold it a moment.
You find -w useless because it has global effect.
But you don't like warnings.pm because it *doesn't* have global effect.
If I understand what you're saying, you think -w will become useful
again if warnings are on by default because module authors will have
more incentive to eliminate them? Human nature says it will just be
an incentive for those same authors to say "no warnings". This just
covers up the problem.
> > I thought this, too. In fact, its in that pseudo RFC I posted way
> > back when as a rationale. After some observation of how people deal
> > with strict, warnings, tests, etc... I really don't think there's any
> > conscious decision there unless the person has already internalized
> > the concepts.
>
> and your point?
>
> > In the same way that I unconsciously type '-wle' in all my one-liners,
> > people will write '-q'.
>
> Fine - let them do that.
But that defeats the purpose of turning strict on by default!!! If
they're not thinking about it, there's no point!
As I understand it the reasons why it would be a good idea to turn
strict and warnings on by default are:
1. so you won't forget to turn it on
2. to save a little typing
3. to make people more aware of the decision to turn it off
But if they have -q and if Perl is too verbose by default, they'll
just shut it off to shut it up, defeating #3. They're not thinking
"yes, I realize this is dangerous to not have warnings on" they're
thinking "god, what's all this crap on my screen?!"
> Most likely, the way the upgrade is going to work is incrementally. RedHat,
> ActiveState, Debian, etc. will silently upgrade their distributions to perl6.
> There is lots more wriggling room than people think.
Do you know how long FreeBSD distributed perl4 as /usr/bin/perl? I
think it was only in 1998 they switched to perl5. FOUR YEARS after
5.000 came out. Why? They didn't want to break their user's
programs.
The more we break compatibility, the longer acceptance will be
delayed. We should not break it without good reason. Those which
have been presented are not good enough reasons.
> It isn't. Like I said, I want to have a global. I want to be able to
> *boom* turn on warnings and strict and have it blanket cover my code.
> I can't do that with the current situation. And this is
> fundamentally broken now.
PERL5OPT='-w -Mstrict'
or
PERL5OPT='-Mwarnings -Mstrict'
Ta da.
> > The upgrade path is made no easier by having to delete "-q" than
> > having to type "use strict". That's totally swamped by the code sweep
> > necessary when turning strict on in a formerly unstrict program.
>
> no it isn't.
No it isn't??? I ASSURE you from many experiences, changing a program
from unstrict to strict is NOT a simple task and typing C<use strict>
is the absolute LEAST of my worries.
Have a look at this patch which turned on strict in everything I could
in the core libraries. File::DosGlob is a good example of one of the
more difficult changes.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00212.html
> > > Again, see up top. '-w' is a global flag, and hence you get thousands
> > > of global warnings.
> >
> > I think this is covered by "use warnings".
>
> No it isn't - '-w' is a global flag for a *reason*. If everybody had a
> warnings policy, it would become useful again.
But the net effect will be worse! Consider, currently there's
three options:
1. You leave warnings off. Not good, but its quiet.
2. If you use C<use warnings> you only get your problems.
3. With -w you get everyone's warnings.
Now, I don't find #3 to be much of a problem. Most modules don't
produce spurious warnings unless they're in early alpha. If something
does spit out lots of warnings, I'm glad to know it because it
indicates either a mistake on my part in using the module or a low
quality module. My solution? Fix my code or fix the module.
Anything else is just sweeping the problem under the carpet.
Anyhow, point is there's a choice.
Now, if warnings & strict are default...
1. You use -q. Not good, but its quiet.
2. You say C<use warnings> and you only get your own problems.
3. You use -w and you STILL only get your own problems!
Why? Because everyone's got a "warning policy" (ie. C<no warnings>).
The net effect is you can no longer see potential problems inside 3rd
party software and there's no way to turn warnings back on that code
except through editing the source. Result? More time spent trying to
figure out what the hell is wrong.
Your warning policy encourages sweeping problems, not just under the
carpet, but into the ocean!
And no, -w should not override C<no warnings> else you'll have
legitimate cases of warning suppression being violated. (See
AnyLoader, Cwd, ExtUtils::MM_Unix, Fatal, etc... for examples).
> > Here's something that came up in earlier discussions that stopped me
> > dead. Many people like to shut off warnings when they ship code. I'm
> > not going to argue the wisdom of this here, but there are valid
> > business reasons to not want end-users to see warnings.
>
> So what? let them do it. As it stands, they have to do this anyways - either
> remove '-w' from their scripts, or remove 'use warnings' from their modules.
As I think I already pointed out to Peter, its usually the case that
-w is on the command line and in their test programs.
> (ps -- as for the modules/scripts thingy... well, I guess I disagree with the
> dichotomy part, but I could see where that would be a tough sell. ah well...)
Came up when I tried this earlier. I drew the line between -e and not -e.
