>> The problem I have with the DEBUG etc keywords is that they promote
>> inefficient behavior. e.g.
>>
>> DEBUG "Current arguments: " . Dumper([EMAIL PROTECTED]);
>>
>> will take the performance hit for Dumper() even when debug logging
>> isn't turned on.
>
> Sure, although I don't see how
>
> $log->debug("Current arguments: " . Dumper([EMAIL PROTECTED]));
>
> is any different.
It isn't different, by itself, but it translates naturally into
$log->debug("Current arguments: " . Dumper([EMAIL PROTECTED])) if
$log->is_debug;
whereas if you start off in easy mode, you don't have any way to get
at the logger (as far as I can tell).
> By the way, in Log4perl you can pass a subroutine ref
> to the method, which eliminates the problem:
>
> DEBUG sub { "Current arguments: " . Dumper([EMAIL PROTECTED]) };
>
Right, I forgot about the subroutine syntax. I do think that is a
little harder for novices, and a little more expensive, than the
conditional (especially when the conditional is against a simple
scalar).
To be honest I have other problems with porting the DEBUG etc
keywords into a generic, universally acceptable API. The all-caps is
not in line with Perl standards, and it interferes with
Carp::Assert's DEBUG. It also introduces a second, less-powerful API
that isn't trivial to convert to the primary API when you need more
features. IMHO it is better to just provide users with an easy way to
create the default logger, and then maintain a single powerful OO
API. My two cents.
Jon
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
