I'm cc-ing this to p6 because there doesn't seem to be anyone left on p5p.
Let me deal with the easy bit first. I've added a convenience function
called "warnings::warnif" that allows you to write this:
warnings::warnif($category, "message") ;
instead of this:
if (warnings::enabled($category))
{ warnings::warn($category, "message") }
I think this is worth having because it is a common idiom and it means that the
caller stack doesn't have to be scanned twice.
Now to the meat. I've made two changes to the way warnings::enabled,
warnings::warn and the new warnings::warnif work.
The first change I reported last week on p5p. Here is a summary for
those that missed it.
Recall that I added a feature in 5.6.0 to allow perl modules to "register"
their module name as a warnings category name and then report
module-specific warnings back to the user of the module when requested. The
problem with the existing code is what the warnings::* functions think the
"user" is. Consider this code:
package abc ;
use warnings::register;
sub doit
{
if (warnings::enabled()) {
#...
warnings::warn("some message") ;
}
}
1 ;
package main ;
use abc ;
use warnings 'abc' ;
abc::doit() ;
Running that I get this message with 5.6.0
some message at /tmp/try line 5
The above case works nicely, but that's just by good luck. Say module "abc"
looked like this:
package abc ;
use warnings::register;
sub really_doit
{
if (warnings::enabled()) {
#...
warnings::warn("some message") ;
}
}
sub doit { really_doit() }
1 ;
#-----
package main ;
use abc ;
use warnings 'abc' ;
doit() ;
In this case the warning in "really_doit" doesn't get reported at all! The
reason is quite simple -- the warnings::(enabled|warn|warnif) functions
only check the warnings bitmask 1 level up the caller stack.
A simple way to partially fix this is to change warnings::(enabled|warn|warnif)
to walk up the caller stack until they find a different package name. I have
made this change in my development copy and it seems to work fine.
I say partially fix, because things get more complicated when inheritance is
factored into the equation. This leads on to the next change I've made.
All of the warnings::(enabled|warn|warnif) functions check for a warnings
category name that match the name of the package they are compiled in
if they aren't specifically given one. This
is fine any dandy some of the time, but what should they check for if they
are being used in a method that has been inherited? Consider this code:
package abc ;
use warnings::register;
sub doit
{
my $self = shift ;
if (warnings::enabled()) {
#...
warnings::warn("some message") ;
}
}
1 ;
package def ;
use abc ;
use warnings::register;
@ISA = qw( abc ) ;
sub new { my $class = shift ; return bless {}, $class ; }
sub dosomething
{
my $self = shift ;
$self->doit() ;
}
1 ;
package main ;
use def ;
use warnings 'def' ;
$a = new def ;
$a->dosomething() ;
What warnings category should the calls to "warnings::enabled" and
"warnings::warn" in "doit" use? I reckon in this situation they should
refer to the object they have been given to decide. To allow for this
I have changed warnings::(warn|enabled|warnif) to optionally accept an object as
their first parameter.
In this case they will then walk the caller tree looking at the first
parameter passed into each sub in turn. This allows the warnings::* functions
to detect the place in the caller list where the object was first used. If
"doit" is rewritten like this:
package abc ;
...
sub doit
{
my $self = shift ;
if (warnings::enabled($self)) {
#...
warnings::warn($self, "some message") ;
}
}
1 ;
the warning will be reported at this line
$a->dosomething() ;
That seems like the right thing to do.
Comments... please?
Paul
