On Thursday 15 February 2001 19:21, Edward Peschko wrote:
> How many times have I wanted to put 'use strict' in a module and
forgotten
> about it?
Then it isn't, technically, a perl problem.
> How many times have I wanted to use '-w' but was not able to because
> of all the junk that comes out of it?
That also, technically, isn't a perl problem.
>
> Make it by default and a large portion of the problem is solved.
Define "large portion" and "the problem."
>
> If you get really used to -q, then it rolls off the fingertips:
> '/usr/local/bin/perl -q'.
If you really get used to "use strict;", then it rolls off the fingertips,
too.
> 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'...
You'd be amazed how many errors *aren't* caught with strict and 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.
What can be more proactive than "Your code should work."?
>
> As for '-T', well, some modules don't *want* to be run in '-T' mode.
Why not? Evvvvvvvvvvvvvvery module should handle untainted data, just in
case, right? That is potentially far more dangerous than using a global in
the wrong package, no?
> 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?
Well, speaking from experience, put one out. There are an unbelievable
number of ways a fire can start, a lot of them unforeseeable. But most
fires themselves fall into a half-dozen classes, with fairly standard
firefighting techniques.
> 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.
So you want to force people to adhere to strict rules, but it would be too
onerous to force them to adhere to strict rules?
(Personally, I don't care about the extra warnings, as long as I can shut
them up. That doesn't really change perl's behavior. Forced strictness
does.)
--
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)
