At 08:41 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote:
>On Fri, Feb 16, 2001 at 03:28:36PM -0800, Edward Peschko wrote:
>In the same way that I unconsciously type '-wle' in all my one-liners,
>people will write '-q'.
Not if we bury the documentation for -q somewhere devilishly difficult to
find... like perlrun. That'll pretty much guarantee that 25% of the
posters to clpm won't find it in their lifetimes.
> > 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.
I absolutely disagree with outputting that message. It defeats the purpose
and trains people to use -q without thinking why.
>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...
Exactly.
>Come to think of it, what language or popular compiler does have
>run-time (not compile-time) warnings on by default?
Er, Perl is loose enough that those run-time warnings substitute for only a
part of the kind of strictness checking that other languages do at compile
time.
>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!
Darwinian selection in action. But if you want P6 to be so backwards
compatible that the largest issues are smaller than "@", an awful lot of
good stuff ain't gonna make it in, it seems to me. 'Sides, we already got
some clues that P6 won't have to be that backwards compatible with P5.
>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.
But why force all the new programs which haven't been developed yet which
will be developed faster and be maintained better if they do get
strictified to be consigned to the same bugginess?
I repeatedly tell people, "If you're handed a program that doesn't have
-w/use strict in it, hand it back and say, Please insert -w/use strict, and
give it back to me when you've eliminated all the resulting messages," and
many of those people have thanked me for that instruction. So far,
no-one's said it was a bad idea.
> > > 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.
Okay, we'll make it so the only way to shut it off is by providing the
answer to an exercise picked at random from Knuth. No, wait, they'll just
end up pasting the answers in from a cheat sheet posted on the net, scratch
that...
>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.
I think I tried that a couple of times :-)
>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.
I don't get this. If someone's developing code right now with "use
warnings", and they want to ship with warnings disabled, they gotta edit
the code anyway. How is commenting out "use warnings" at release time
different from inserting "no warnings" at release time?
And if they're developing the code all the way through without warnings (in
which case they don't deserve to have customers), then they'll just put "no
warnings" or -q in there from the start and there's no release editing
required.
--
Peter Scott
Pacific Systems Design Technologies
