Proposed enhancement to the warnings pragma for Module writers
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
RE: Proposed enhancement to the warnings pragma for Module writers
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Sun, Aug 13, 2000 at 09:36:48PM -0400, Ronald J Kimball wrote:
> > On Sun, Aug 13, 2000 at 09:04:41PM +0100, Paul Marquess wrote:
> > > I'm cc-ing this to p6 because there doesn't seem to be anyone left on
p5p.
> > Then who is generating all this traffic on p5p? :D
>
> I'm certainly still there, as you can tell from everyone correcting my
> patches. :)
Sorry guys, forgot the smiley.
> > > warnings::warnif($category, "message") ;
> > >
> > > instead of this:
> > >
> > > if (warnings::enabled($category))
> > > { warnings::warn($category, "message") }
> >
> > Any reason why that isn't the behavior of warnings::warn()?
>
> Because there are occasions when you want to force a mandatory warning.
Correct.
Paul
RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Provide a standard module to simplify the creation of source filters
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 20 September 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 264
> Version: 1
> Status: Developing
>
> =head1 ABSTRACT
>
> This RFC proposes that the interface to Perl's source filtering facilities
> be made much easier to use.
>
> =head1 DESCRIPTION
>
> Source filtering is an immensely powerful feature of recent
> versions of Perl.
> It allows one to extend the language itself (e.g. the Switch module), to
> simplify the language (e.g. Language::Pythonesque), or to
> completely recast the
> language (e.g. Lingua::Romana::Perligata). Effectively, it allows
> one to use
> the full power of Perl as its own, recursively applied, macro language.
>
> The Filter::Util::Call module (by Paul Marquess) provides a usable Perl
> interface to source filtering, but it is not nearly as simple as
> it could be.
>
> To use the module it is necessary to do the following:
>
> =over 4
>
> =item 1.
>
> Download, build, and install the Filter::Util::Call module.
>
> =item 2.
>
> Set up a module that does a C.
>
> =item 3.
>
> Within that module, create an C subroutine.
>
> =item 4.
>
> Within the C subroutine do a call to C, passing
> it either a subroutine reference.
>
> =item 5.
>
> Within the subroutine reference, call C or
> C
> to "prime" $_ with source code data from the source file that will
> C your module. Check the status value returned to see if any
> source code was actually read in.
>
> =item 6.
>
> Process the contents of $_ to change the source code in the
> desired manner.
>
> =item 7.
>
> Return the status value.
>
> =item 8.
>
> If the act of unimporting your module (via a C) should cause source
> code filtering to cease, create an C subroutine, and
> have it call
> C. Make sure that the call to C or
> C in step 5 will not accidentally read past the
> C. Effectively this limits source code filters to line-by-line
> operation, unless the C subroutine does some fancy
> pre-pre-parsing of the source code it's filtering.
>
> =back
>
> For example, here is a minimal source code filter in a module named
> BANG.pm. It simply converts every occurrence of the sequence
> C
> to the sequence C in any piece of code following a
> C statement (until the next C statement, if any):
>
> package BANG;
>
> use Filter::Util::Call ;
>
> sub import {
> filter_add( sub {
> my $caller = caller;
> my ($status, $no_seen, $data);
> while ($status = filter_read()) {
> if (/^\s*no\s+$caller\s*;\s*$/) {
> $no_seen=1;
> last;
> }
> $data .= $_;
> $_ = "";
> }
> $_ = $data;
> s/BANG\s+BANG/die 'BANG' if \$BANG/g
> unless $status < 0;
> $_ .= "no $class;\n" if $no_seen;
> return 1;
> })
> }
>
> sub unimport {
> filter_del();
> }
>
> 1 ;
>
> Given this level of complexity, it's perhaps not surprising that source
> code filtering is not commonly used.
Whilst I don't have any problems with you module, I think you are
overstating the complexity of the existing situation. This should be all
that is needed to create your filter.
package BANG;
use Filter::Util::Call ;
sub import
{
filter_add( sub {
my ($status);
s/BANG\s+/die 'BANG' if \$BANG/g
if ($status = filter_read()) > 0 ;
$status ;
})
}
sub unimport
{
filter_del() ;
}
1 ;
> This RFC proposes that a new standard module -- Filter.pm -- be
> provide to vastly simplify the task of source code filtering,
> at least in common cases.
Can I suggest you feed data a line at a time rather than the series of lines
as you do right now. That makes it work like the existing filters.
I'm not sure Filter is the best name for this. How about Filter::Transform
or Filter::Simple?
Paul
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters
From: Damian Conway [mailto:[EMAIL PROTECTED]] ... > > No. That's my point. I want to match BANG followed by maximal whitespace > followed by another BANG. But a line-by-line filter fails dismally if that > maximal whitespace contains a newline. > > Admittedly this particular example is contrived for effect, but I have > now used your excellent module in numerous projects when constructs *can* > cross newline boundaries and it's always painful to do (hence the new > module). In fact, I would claim that filtering constructs across > newline boundaries is the *norm*, since newlines are just whitespace most > places in Perl. Aaah! I see where you are coming from now. Is that mentioned in the RFC and module docs? If not, it really needs to be emphasised. It completely passed me by. If you like, next time I do a Filters release, I'll update my documentation to mention your module. Paul _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... > > The basic usefulness of warnings is not in question. This is about > the *perception* of their utility. Warnings are only useful if the > user heeds them. The question is, will having them on by default make > the user more or less likely to respond? > > There was also eariler discussion that this might encourage people to > cover up large sections of lousy code with a C thus > further burying potential errors and actually worsening the situation. > Some ideas were kicked around to have a way to globally override C warnings>... This is what the -W command-line flag does. > but it seems like we're right back to having to remember > -w again. Paul _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: :, ::, :::, and :::: in P6REs
> The behaviour is explained quite well in E5 I think. Is that the "soon to be released" E5? Paul
RE: :, ::, :::, and :::: in P6REs
> > Is that the "soon to be released" E5? > > No, that's the "to be released today" E5. > > ;-) Yy!!
