NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Great work, and can I have stealth loggers? (Score:1)
It is really unfortunate that important CPAN modules like LWP or Rose::DB don't have usable logging mechanisms in place. Once you're used to category-based logging it's hard to go back to these home-grown and less convenient solutions.
I think it's a great idea to promote standardized logging on CPAN and letting the user choose the actual implementation will definitely help to make strides towards that goal.
By the way, I don't agree that
Re:Great work, and can I have stealth loggers? (Score:1)
> minimize dependencies, depending on Log4perl (for example) is a
> non-starter." The Log4perl core doesn't have dependencies other
> than perl's core modules.
Fair enough.
>
> One thing missing from your proposal is Log4perl's
> [sourceforge.net]. If you think about it, getting a logger and
> calling its method is a lot of typing, given that you just want
> to log something. That's why in Log4perl you can use
>
> DEBUG "Log this!";
>
> and you're done. No getting a logger, no method calling, no
> category passing. It's all automatic. Behind the scenes, it gets
> a 'stealth logger' with the category set to the current package
> and calls the appropriate logging method on it. This feature is
> huge. I'm using it almost exclusively in everything I write.
>
> Any chance of adding that?
Did you see this in the posting?
As a convenient shorthand, you can use
package Foo;
use Log::Abstract qw($log);
to create the logger, which is equivalent to the first example except that $log is
(necessarily) a package-scoped rather than lexical variable.
So this creates a logger for you with the category set to the current package, similar to easy mode. The syntax is pretty minimal. The problem I have with the DEBUG etc keywords is that they promote inefficient behavior. e.g.
DEBUG "Current arguments: " . Dumper(\@_);
will take the performance hit for Dumper() even when debug logging isn't turned on. This may be fine for a particular application where performance is not an issue, but I would never want to encourage any CPAN module author to do this.
In fact, in this thread on perl.module-authors,
http://groups.google.com/group/perl.module-authors/msg/cbd5a168d5d780a8?hl=en& [google.com]
it was suggested that even the usual "fast" $log->is_debug() check is too much of a hit. So I proposed we export a live $log_is_debug variable that would change dynamically to reflect the current level.
I suppose one could combine the syntaxes:
DEBUG "Current arguments: " . Dumper(\@_) if $log_is_debug;
but at this point you are only saving 6 characters or so.
>
> One thing to watch out for is performance. People don't want
> their applications to slow down just because a module has a
> logging capability.
Exactly my point above.
Thanks for your positive feedback! I will definitely need to have the support of major logging frameworks such as log4perl for this module to be a success.
Reply to This
Parent
Re: (Score:1)
> package, similar to easy mode. The syntax is pretty minimal.
Ah, gotcha. So you would call
$log->debug(...)
instead of
DEBUG "..."
which is probably acceptable in terms of additional key strokes
(although it might throw off novices).
> The problem I have with the DEBUG etc keywords is that they promote
>inefficient behavior. e.g.
>
> DEBUG "Current arguments: "
Re: (Score:1)
Assertions were going to make that possible in 5.10.
Unfortunately they were recently removed from bleadperl. :-(