[ cc-ed to perl5-porters ]
On Tue, 12 Dec 1995 10:21:05 GMT, Ian Phillipps wrote:
>
>> > >Sorry, I must differ on this. All-lower-case bare words are dangerous:
>> > >they might be reserved in a later version of perl, or you might "use" a
>> > >module that exports the routine "abc".
>
>> > braced-hashkey-barewords as strings. So it will never fail, only incite
>> > ugly warnings with -w.
>
>> No, you will get no warning in this context (unless you get a _real_
>> conflict with an existing function).
>
>Indeed: this is my justification for calling it dangerous. A program
>which runs cleanly now may suddenly start to produce warnings - lots of
>'em - in the future if another subroutine is added to it, if a new
>keyword is added to Perl or if the author of one of modules used decides
>to add a new item to its EXPORT list.
>
>If you're upgrading Perl versions, the last thing you want is to be
>confronted by lots of worrying (but useless) warnings.
>
Coupled with the boolean nature of the -w switch, the tendency for some
(many ?) people to run production code with -w, what is a useful feature
might not be very usable, after all. The Todo list's "multiple levels of
warning" will put an end to this, when it gets implemented.
Come to think of it, it is not too difficult to do, I'll see
if my patch toaster will produce something edible if I get some
time off to cook it. Meanwhile, I'm accepting suggestions.
Here's are the barebones:
* classify the perl warnings into several levels (hard) -- how
many? Which are more serious and why? I'll sift through the
warnings and post a stratified list soon.
* make "dowarn" into something more than a boolean -- a macro
that accepts a numeric arg, perhaps (easy).
* -w ==> -w[n]
$^W = $warnlevel;
* (if I have lots of time after the above) write a proper warn.pm so
you can do
use warn 3;
{
no warn qw(W2_UNINIT W2_BARESTR);
...
}
Inhibiting specific warnings will of course be implemented
via __WARN__ so perl efficiency will not suffer. This will
likely need a more regular format for warnings and errors
that can be more reliably parsed inside a warn hook without
fear of failing when a new warning gets implemented.
I'm especially going to need comments on the first, based on your
personal experiences, from answering novice questions, etc.
- Sarathy.
gsar@engin.umich.edu
On Tue, 12 Dec 1995 10:21:05 GMT, Ian Phillipps wrote:
>
>> > >Sorry, I must differ on this. All-lower-case bare words are dangerous:
>> > >they might be reserved in a later version of perl, or you might "use" a
>> > >module that exports the routine "abc".
>
>> > braced-hashkey-barewords as strings. So it will never fail, only incite
>> > ugly warnings with -w.
>
>> No, you will get no warning in this context (unless you get a _real_
>> conflict with an existing function).
>
>Indeed: this is my justification for calling it dangerous. A program
>which runs cleanly now may suddenly start to produce warnings - lots of
>'em - in the future if another subroutine is added to it, if a new
>keyword is added to Perl or if the author of one of modules used decides
>to add a new item to its EXPORT list.
>
>If you're upgrading Perl versions, the last thing you want is to be
>confronted by lots of worrying (but useless) warnings.
>
Coupled with the boolean nature of the -w switch, the tendency for some
(many ?) people to run production code with -w, what is a useful feature
might not be very usable, after all. The Todo list's "multiple levels of
warning" will put an end to this, when it gets implemented.
Come to think of it, it is not too difficult to do, I'll see
if my patch toaster will produce something edible if I get some
time off to cook it. Meanwhile, I'm accepting suggestions.
Here's are the barebones:
* classify the perl warnings into several levels (hard) -- how
many? Which are more serious and why? I'll sift through the
warnings and post a stratified list soon.
* make "dowarn" into something more than a boolean -- a macro
that accepts a numeric arg, perhaps (easy).
* -w ==> -w[n]
$^W = $warnlevel;
* (if I have lots of time after the above) write a proper warn.pm so
you can do
use warn 3;
{
no warn qw(W2_UNINIT W2_BARESTR);
...
}
Inhibiting specific warnings will of course be implemented
via __WARN__ so perl efficiency will not suffer. This will
likely need a more regular format for warnings and errors
that can be more reliably parsed inside a warn hook without
fear of failing when a new warning gets implemented.
I'm especially going to need comments on the first, based on your
personal experiences, from answering novice questions, etc.
- Sarathy.
gsar@engin.umich.edu