Re: [Pas-dev] Suggestion for logging

[Kyle R. B. <mo...@vo...>]

> >      if( $log->is_debug() ) {
> >        $log->debug("somethingComplicated, self = ", Dumper($self) );
> >      }
> 
> I like everything except the if $log->is_debug. I haven't looked into or
> spent more than 2 seconds thinking about implementation, but wouldn't it
> be easier if you just wrapped it (log4perl) with Org::Bgw::Log? Then you
> could just call $self->log()->debug like usual. Let the wrapper do the
> debug level check and just return if its not set. IF it is set, it can
> call its getLogger method and log stuff. It'll be better separation
> between page objects and log levels. It'll avoid needless instantiations
> of the lob ogject and simplify the interface.  Know what i mean? 

"if( $log->is_debug() ) {" is an _optimization_.  You don't have to use it.
In the example case I gave, the point was that "Dumper($self)" could be
an _expensive_ operation to perform at run-time -- for Dumper to produce
the string representation of "$self".  If you didn't wrap the call with
the "is_debug" test, then Dumper is invoked, the argument list for the
"debug()" call is built (which might be expensive), "debug()" is called,
and then it decides to throw away all the work that Dumper did because
the log level isn't high enough.  Does this make sense?  

You don't have to use "is_debug" (or is_info, is_error, etc.) if you don't 
want to.  The thing to keep in mind is that the argument list you put
in your code gets computed regardless of the log level.  The conditional
prevents that code from executing.

Log4perl already does the "is_debug" test internally, the example there
was just to point out that inefficiencies existed and one approach for
overcoming them.


As for the "$self->log->debug" approach automatically detecting the caller
and constructing the logger, you could wrap all of it that way.  The
issue with that, I beleive, is again overhead and efficiency.  If having
all these instantiated loggers turns out to be an issue then we can
explore optimizing it.  Based on my experience using Log4j it has yet
to be an issue - the logger instances tend to be very light weight.

> That and depending on the names of the log levels it'd be a transparent
> change. The only differences would be config file stuff and suddenly you
> can log on a per-package basis. 

There are good reasons to follow the convention of using the package name,
but there can also be good reasons not to.  You might want to mix
metaphores in the code - you might actually want to use a specific logging 
context for any of a few reasons -- maybe you want to include a database
reference in the logging context, or a different context for administrative
users logged in to your software.  

The logging infrastructre could also be used for reasons other than code
inspection - you might want it to act as a simple insturmentation api.
The use of a 'profile' log context could allow you to enable/disable
in-code insturmentaiton of portions of the codebase.


Thanks for the discussion.

Kyle




-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------