# from John Siracusa
# on Thursday 06 September 2007 06:58 pm:
>On 9/6/07 4:14 PM, [EMAIL PROTECTED] 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
---------------------------------------------------
