I guess this was what was meant by 'put your asbestos gloves on'.
On Thu, Feb 15, 2001 at 07:57:31PM -0500, Bryan C. Warnock wrote:
> 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.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
> > 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.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
> > Make it by default and a large portion of the problem is solved.
>
> Define "large portion" and "the problem."
The problem is stability/usability of modules on CPAN. The 'large portion'
of problems is the errors caused by people not using '-w' and 'strict' on their
modules causing run-time errors.
> > 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.
yeah, but I covered this down below. If you forget '-q' it isn't that big
a deal, its easily found. If you forget 'use strict'....
ANYWAYS, READ MY POST AGAIN ABOUT WHAT HAPPENS IF YOU FORGET 'USE STRICT'
BEFORE YOU SAY SOMETHING LIKE THIS.
> You'd be amazed how many errors *aren't* caught with strict and warnings.
This is irrelevant. I never said it would fix the world.
> What can be more proactive than "Your code should work."?
Its the enforceablity of that concept.
What I'm saying is that if you *really* want a revolution, try to force people
to only be able to release their modules *until* it works on a large number
of platforms. If you used that as a criteria, perl itself would never get out
the door. ( witness the number of bug reports on perl5-porters )
> > 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?
well, no, actually. Some modules evaluate code given on the command line, and
are quite useful. And regular expressions can take - as an argument -
unevaluated code through ?{}.
> That is potentially far more dangerous than using a global in the wrong
> package, no?
That's why -T exists. You can turn it on if you are going to be using it in
suid scripts, and boom, it gives you a list of errors.
But the point is that sometimes things that are taint-unsafe are useful. And
hence you can't use a blanket evaluation mechanism, it has to be done case
by case.
> > 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.
ok, let me put it another way - why start fires just so you can put them out?
> > 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?
I think that there is a basic misconception here - there is NO FORCING GOING
ON. The only thing I'm 'forcing' people to do is come up with a policy towards
warnings or strictness. Who am I to say a module writer if he/she wants to put
'no strict; no warnings' in his/her module?
The fact is, though, that people will get used to the extra safety blanket that
these two things give, and I bet people will use it 75% of the time if not more.
And we'll all be better off.
And anyways, yeah, there's a big differnce between a use strict policy, and
making a module work on 20 different platforms before it can be published.
The manpower might not be available. the equipment might not be available. The
module owner might not WANT to port his module to multiple platforms. And so
on and so on and so on.
> (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.)
Exactly. You can shut them up with 'no warnings' or '-q'. There is no such thing
as 'forced strictness', that's a straw dog that's unfortunately relatively
easy to beat.
Ed
