> print <<IRONY;
> I consider a module without tests or documentation to be a syntax
> error. Maybe perl should refuse to run a module without POD and
> MakeMaker should refuse to install a module without tests unless given
> a special flag. Then people will sometimes forget to use that flag
> and they'll be reminded of the importance of writing documentation and
> tests.
> IRONY
hey look, all it is is a question of balance. Like it or not perl already
forces upon you a series of inconsistancies in syntax, misunderstandings,
special cases, weird characters, etc.
These *also* are constraints that make newbies tear their hair out - and both
'-w' and 'use strict' help *clear up* those things. Primarily they aren't
procedural things, they are switches that help deal with the *language itself*.
And yes, they should be made easy enough for newbies to learn. Probably easier
than they are now.
The things you mention are procedural. And as tempting as it is to enforce a
little vigor on procedure, I agree with you. I don't want to make a coding
architecture on by default..
> > And when they do, they will either immediately add '-q' to their scripts and
> > ignore the warnings, or they will actually think about the errors that are
> > coming on their screens.
>
> Unfortunately at this point, they will probably be overwhelmed with
> warnings and fixing their program to run clean will take a relatively
> large effort. The benefit will not be clear, it'll just look like
> lots of busy work.
Oho! Now we are getting somewhere. I never said that I want to keep warnings
as they currently are... They should be a hell of a lot more intuitive than
it is currently. And I agree with you that it has severe shortcomings as it
is currently designed.
I want to make it *simple* and *intuitive* enough so it can be turned on by
default. That is a pre-condition for them being added to as default.
> The problem is, fixing errors (and warnings) should be an iterative
> process. The way you expect -q to be used discourages this. There's
> nothing worse than suddenly seeing a flood of warnings from your code.
> We've already been around in circles on this. As above, I'll agree to
> disagree.
>
>
> > use Carp;
> >
> > my $a = undef;
> > carp($a);
> >
> > When I run this under 'use warnings', I get the following.
> >
> > Use of uninitialized value in join at
>/home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 164.
> > Use of uninitialized value in join at
>/home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 31.
> >
> Let's use this as a test case of the wonders of making warnings
> default and the magical results it will have on cleaning up the perl
> core libraries. You are aware of a bug, you're even rather annoyed by
> it, and you're accutely aware of its existance due to a warning. But
> you've done nothing about it.
But I don't think it is a bug - in perl, or in 'carp'. I think its a bug in
the person's code. And in the way warnings are handled. I'd want this to say:
Use of unitialized value passed to function 'carp' at line 4.
> Why haven't you fixed this? Why haven't you even reported this?! Why
> isn't this a test case??
Again, I don't think it is carp's fault. I think its the programmers fault.
> I'm sorry if this sounds like a personal attack, but its a perfect
> illustration of how easily and often minor warnings are ignored and
> how turning them on isn't going to make a dent in the community's
> psychology towards minor warnings. Even you have the subconscious
> attitude "oh, somebody else will fix it" (unfortunately, that somebody
> is too often me, Perl's garbage man).
yeah, well 1) its not a personal attack, its an attack of an idea. And 2)
you are right, as warnings stand, it won't make a dent in the attitude towards
them.
As for the 'oh, somebody else will fix it', well that's what I'm trying to do
- distribute the load. It has to be workable, warnings have to be on by default
and there has to be *incentive* for people to fix them. Enough incentive that
they aren't turned off in large numbers.
> The fix, BTW, is simple. The warning points directly to the problem.
> A minute spent examining Carp::Heavy shows all that's necessary is to
> remove the assumption that @error is defined (this is the Carp::Heavy
> from bleedperl).
>
> - my $err = join '', @error;
> + my $err = @error ? join '', @error : 'undef';
But this is too verbose, and it is doing something that should be done by
default with warnings. If I pass a bad value to a function, the language should
be smart enough to warn me in the correct place without me doing anything.
And anyways, that's not simple enough. You'd have to say something like:
my $error = join('', map((defined($_))? $_ : 'undef', @_);
since any of the arguments could have undef values in them.
> And then to write a test to ensure it doesn't happen again.
>
> If you're not willing to do it, why should you assume anyone else is?
> I can't fix up the whole distribution alone.
>
> Ed, you're your own counter-example. You'll find you're not the only
> one, few people want to do this sort of work.
Like I said, that's the idea - turning on the defaults goes a ways towards
distributing the workload.
And part of this has to be making the warnings/strict process simpler to use
than it currently is or you may be right, people might bury their heads in the
sand.
And - btw - I too have done several fixes of this type, albeit on third party
modules. As for the 'error', well I picked it out of the air just to show how
easy it was to do. I didn't have to look long. :-(
> I'll stop the argument there, I think we've yelled at each other long
> enough. Write up the RFC if you'd like, but I'd request that you
> provide a pointer to this specific post. I think it most elegantly
> sums up my objections.
well, I prefer the term 'vigorous debate', but, ok, I'll write one up, and
I'll point to this specific post in any way or shape you see fit, but I'd like
to hear your comments on it, point by point.
And I'd like to post it to 'perl6-language' rather than 'perl6-language-strict'.
Hell, we are talking primarily about *warnings* here, not strict.
Ed
