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"?
> > I'm not sure what you mean by a policy. Do you mean you want people
> > to have to say C<no strict; no warnings;> explicitly? Do you want to
> > make it a conscious decision to shut off the safeguards?
>
> Yes!
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.
In the same way that I unconsciously type '-wle' in all my one-liners,
people will write '-q'.
> If you put a note in the script after each time an error comes up,
> something like:
>
> Global symbol "$ab" requires explicit package name at a line 5.
> Execution of a aborted due to compilation errors.
> ----
> NOTE - if you are seeing this error and wondering what the hell it means,
> perl's policy towards errors has changed since perl5. It now
> checks for declarations stronger than it did before. If you want
> the old behaviour, use the '-q' switch. If you want to disable
> these upgrade messages, do xxxx.
>
> People will get the point pretty quick.
No, people will just shut it off pretty quick. This gains nothing.
> > Now I'm completely lost. Making perl quiet is a *bad* thing in the
> > long run. Its a symptom of a lack of programming discipline. That
> > you're giving up on trying to make your program run properly.
>
> Think of it this way - you'd sell '-q' as 'training wheels' for your
> bike. Something to soften the learning curve.
But if you're advocating new programmers should shut perl up, why have
it on by default?! Just to save a little typing?
Trust me, having to type '-q' will not mean people will think about
it. They'll just say "gee, that's annoying" and type it in. Lead a
horse to water, etc...
Come to think of it, what language or popular compiler does have
run-time (not compile-time) warnings on by default?
> > We have a case where the two sides win conditions are conflicting.
> > Keeping strict off has one major advantage, it won't break any
> > existing code. Turning it on by default will break probably the
> > majority of code out there. That would be Bad. We don't want
> > everyone to have to run their entire code-base through p526. The net
> > result will be people running 5.6 in 2010.
>
> No, as far as I know we will be able to put 'use perl5' up on top of
> their scripts, and they will convert over in their leisure.
You'd be amazed at the sort of excuses people will use to avoid
upgrading. The fairly innocent "[EMAIL PROTECTED]" to "foo\@bar.com"
incompatibility has kept many companies down at perl4 even still
today!
> > Yes, people will find it and they will use it. Thus defeating the
> > point of having warnings and strict default.
>
> No it doesn't. Like I said, they will use it - hopefully later on they
> will discard it. It provides an easier upgrade path because it makes
> people type *less* and it puts strict and warnings up front
Ok, saving ten characters of typing per file is not a valid reason to
do anything, so nix that.
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.
> > Assuming a policy is C<no warnings; no strict>, what's the net gain
> > here? What does having this in hand really do for us?
>
> See up above. The policy towards warnings and strict is default positive,
> and takes an action to become negative. In my experience, people focus
> on the default behaviour.
There is no win here. People will shut it off without thinking.
> 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".
> > Is this different than a perl6delta man page? I must have missed
> > this, too.
>
> the point is that the notes would come at the bottom of every single
> compilation. They would point out - by example - exactly where perl5
> and perl6 differ.
<snip>
> WARNING: scalar assignment to a list. NOTE - this has changed since perl5
> $a = $b, $d now parses as ($a = ($b, $d))!
This would be a very useful feature to have, but its FAR too verbose
for day-to-day usage. If you want to see a similar effect, try
developing your code with "use diagnostics" on ALL THE TIME.
Its useful, just not as the default.
> I disagree. Like I said, I think a compromise can be made - provide
> strictness by default in modules, and non-strictness in scripts. That
> satisfies me.
Splitting the language is extremely dangerous, but we're covering that
in a different thread.
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 if warnings are on by default, how do you shut them off? You
either must edit the code as part of the build/distribution process or
provide a wrapper program which runs it under -q. This assumes you
even *have* a build process. Many (most?) places don't.
In order to ship code with warnings off you must
1 - have a build process (not a simple task)
2 - edit the code automatically.
#1 is hard enough. Its desireable, but still very difficult (mostly
political and social reasons in any size organization). But #2... I
really, really, really don't want to require anyone to have to
automate the editing of Perl code.
