Re: Module Proposal: Log::Any

# from John Siracusa
# on Thursday 06 September 2007 06:58 pm:

>On 9/6/07 4:14 PM, swartz@xxxxxxxxx wrote:
>> So why do CPAN modules eschew the use of these and invent their
>> own mechanisms that are almost guaranteed to be less powerful?
>
>I agree with all your listed reason, but I think you missed one:
> minimum overhead.  Ideally, logging would disappear entirely from the
> code path when disabled.  

Agreed.  Most modules are small enough that the author has decided to 
completely disable any debugging code (via a constant or just deleting 
it) before it gets to CPAN.

> Perl being Perl, this is rarely possible, 
> but that doesn't mean the other extreme--at least one method call per
> log line--is suddenly attractive.

Also agreed.  Barring magic, no logger is going to be universally 
accepted (and of course, for some authors, the very presence of "magic" 
means it won't be accepted.)

That doesn't mean that you can't add logging as needed for your large 
applications.  But why do you need to control logging in some other 
module?  (In production code?)

If your goal is simply to save authors the trouble of inventing their 
own logger, another module is maybe not the answer.  Education isn't 
easy, but I'll guess that is mostly what is lacking.  (Isn't it 
always?)

As large applications go, there are always various policy (e.g. we 
install a $SIG{__WARN__}) and workaround issues (such as 
Log::Log4perl's inability to load a module from PAR due to a failed 
reimplementation of eval {require()}.)

  http://svn.dotreader.com/svn/dotreader/trunk/lib/dtRdr/Logger.pm

It would be nice to be able to simply subclass a straightforward, 
efficient, easily/cleanly configurable, and powerful logging module.  
If you write it, I will use it.

> Here's a brief microbench showing 
> the range of overhead for disabled logging:
>...
>(I commented out the constant case because it's best case, as close as
> Perl can come to actual code removal (depending on where/when the
> constant sub is defined).)

The "code not there" (constant) case is *insanely* faster.  I'll take 
that one in my production code please.

Perhaps a core hack would enable it to be turned on and off within a 
long-running process?  Which reminds me: universal acceptance is also 
contingent on being compatible with perl 1.0 (well, something 
ridiculously old like 5.6.2.)  Tough crowd, eh? :-D

Cue discussion of imaginary versions of perl5 such as 5.i.0.  Mine will 
cleanly cross-compile all of CPAN onto linux-MIPS as soon as I finish 
ExtUtils::MakeMaker v5.i.1 ;-)

--Eric
-- 
"It ain't those parts of the Bible that I can't understand that
bother me, it's the parts that I do understand."
--Mark Twain
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------