On Thu, Feb 15, 2001 at 02:54:37PM -0800, Nathan Wiger wrote:
> Edward Peschko wrote:
> > Right, but what I don't understand is that its two extra characters at the end
> > of a command line... whats the big deal about typing '-q' on one line in
> > scripts? Its easy enough to advertise '-q' and put it in big lights...
>
> Yes and no, I think. As Alan Burlinson pointed out earlier, this is
> *not* a purely clean-slate we have here to work with. There are lots and
> lots and lots of users who know how Perl works. Many of these users
> don't even know that you can do this:
>
> my $x = 5;
>
> Let alone that this:
>
> my $x, $y, $z;
right, but that's a pretty small issue. For one, my *would* be more well known
if perl had a default stricter policy. And preventing pain is a simple matter
of people knowing that '-q' exists and advertising that fact. You could even
put the message in the output for the error as an upgrade note:
Global symbol "$ca" requires explicit package name at aa line 2.
Execution of aa aborted due to compilation errors.
-----------
NOTE: to perl5 users - by default, perl is doing more up-front error checking.
To get the old behavior, you can say 'perl -q' in front of your scripts, as
in:
#!/usr/local/bin/perl -q
(although ultimately the error checking can help quite a bit in tracking down
errors. see 'use strict' and 'use warning' in the manual.)
-----------
I think that notes like these tied to the executable are going to be big
helpers in migrating people up in general. And my guess is that there are going
to be a lot bigger issues than this to face for upgrading people.
my $x, $y, $z;
> Doesn't DWIM, again according to what most people think.
It would DWIM if I had my druthers.
> > write scripts without 'use strict'. I do this all the time. But I really think
> > that its a small price to pay to put '-q' on the #!/usr/bin/perl command line
> > for the vast benefits that it would give us all as far as CPAN goes.
>
> Let's separate the CPAN thing out for a moment. "use strict" and "use
> warnings" are not the universal solutions to CPAN quality issues, at
> least as far as I'm aware.
No of course not the 'end all be all'. But they are a large, large, large
part of it. Its proactive thinking versus reactive thinking. It forces module
writers to *have* a warnings policy and a strict policy.
How many times have I wanted to put 'use strict' in a module and forgotten
about it? How many times have I wanted to use '-w' but was not able to because
of all the junk that comes out of it? Too many to count...
Make it by default and a large portion of the problem is solved.
> As for the -q thing, I think it is far *less* of a burden to add "use
> strict" and "use warnings" when you're writing a big piece of code. When
> you're writing 5 lines, every extra character counts. When you're
> writing 500 or 5000 lines, 2 lines of "use" statements are nothing.
well, take the two possible cases:
1) With -e, you have no extra characters to type.
2) With -q, you have two extra characters to type.
If you get really used to -q, then it rolls off the fingertips:
'/usr/local/bin/perl -q'.
And in the rare case that you forget '-q', you'll get instant feedback from
all the errors that you get.
Now take the opposite case. That you forget 'use strict'.
In this case, you can - and I have - looked at it for hours to find the errors
that I missed. And worse yet, these are runtime errors. And then I realize that
I meant 'use strict' and typically whack my head a couple of times.
> > So - in the place of a '-q', would you support a mechanism for making
> > sure that CPAN is '-w' clean? If so, how would you enforce it?
>
> Absolutely, 100%. But this is a separate issue. For example, a big
> problem with CPAN is also packaging. There's lots of modules that don't
> use the h2xs/Makefile.PL approach. Also, many modules on CPAN have been
> in beta for years, and not just 0.99 beta but 0.02 beta, broken and
> uninstallable. There's also a lot of modules that don't run under -T.
> But "strict" won't fix these issues.
of course, but they will fix a large part of them. You'd be amazed how many
errors will be caught with 'use strict' and 'use warnings'...
> If we're interested in increased CPAN quality, there's a bunch of stuff
> we can do. We can have a standard test suite that's run against every
> module uploaded to check if it's installable and compiles basically. We
> can check for -w, -T, use strict, and tons of other stuff. We can check
But we don't want to check for '-w' and 'use strict'. We want to leave that up
to the module owner. All I want is a clear policy towards warnings and strict.
Thats a hell of a lot easier to achieve with something proactive.
As for '-T', well, some modules don't *want* to be run in '-T' mode.
The 'installable' part is intriguing, but then again there are problems with
feedback - do you allow a module to be uploaded if it doesn't compile against
system b, and c but works flawlessly for a,d,e, and f?
In my experience, its always been the proactive policies which work the best.
Reactive policies have lots of shortcomings and are hard to set up. Which is
easier to do - prevent a fire or put one out after its started?
> for the packaging to make sure that "perl -MCPAN -e shell" will install
> the stuff cleanly. If there's simple problems (misnamed tar files, a
> $VERSION split onto multiple lines), we can even auto-fix this. Then
> send all the results to the user who uploaded the module.
that's all cool. But when I come to download the module before the user has
a chance to fix it - and he/she has no warnings policy, that still doesn't help
me with my '-w' problem. Or protect me from the extra errors in those modules.
> Heck, I'd even volunteer to head up a project to do this. But I think
> it's a separate issue from "use strict" and "use warnings", let's not
> confuse the two.
But that's the point - *by* confusing the two, you get lots of benefits at much
lower cost. The '-w, strict by default' thing is proactive and helps everybody
as soon as someone uploads a perl6 module to CPAN.
And the more I think about it, you cannot make the project you describe
proactive - ie: we will not accept your module *until* conditions x,y,z occur -
this would be too onerous to accept for module developers. Far more onerous than
'-q' on simple scripts.
So the project you describe would have to be reactive. And yes, it would help
out quite a bit. But it would be a *very* large project in terms of effort.
Ed
