1. Background
Hi all, first time posting.
This message is in response to Andrei's first call for feedback on the
proposed std.log interface.
I'm piping up on the log topic because of recent experience using a
logging library ("log4cxx") on a project at work.
I'll attempt to identify our teams' requirements of the logging library,
and transition into suggestions for D's "std.log", and why D is a
powerful language in which to implement a versatile log.
I also, in these suggestions, dare make the assumption that the goals of
std.log include accommodating audiences and users similar to my humble
team members and myself. If this assumption is incorrect or the scope of
the suggestions is too large for std.log, by all means pull me back down
to Earth.
2. Requirements (for our team's logging functionality), and features
which accommodate them
- Must be scalable with respect to project size
-- Feature: Allow custom log destinations specified at compile or
run-time, and log level options specified at logger instantiation
(compile time) or at run-time.
-- Feature: Allow loggers to exist in a hierarchy, in which properties
of parent loggers are shared with children.
--- Our team of 18 developers must make judgments about what to log and
when. Depending on the diagnostic activity, it is necessary to
enable/disable logging in specific domains of the application. The
ability to shut off logging in certain parts of the program at run time
is paramount to success in debugging certain issues, from our experiences.
--- The hierarchy helps in being able to shut off a large branch of
loggers by specifying the level for just one ancestor. Also the
hierarchy format (at least in our case) maps well to the organization of
objects across our domains.
- Must be performant
- Log calls and interaction must be concise, readable code
-- Feature: Minimal setup code, minimal code at log call site
--- Our team has felt the pain of supporting and troubleshooting our
products at customer sites, with irate customers present. Each
illuminative log statement is worth it's weight in gold, but we're also
cognizant of maintainability of software, and code with verbose comments
becomes difficult to read.
--- I opine: the current interface for std.log currently achieves good
readability! Awesome!
-- Feature: Allow code/logic to be run inside the conditional block of a
log call.
--- An example of our need for this is the need to print specific data
from each member of a list of objects. Rather than incur log call
overhead on each iteration over a list (much less not being able to
compile away that logic), the most efficient solution seems to be
allowing logic in the log conditional block.
--- Of course, somebody somewhere will misuse this and put "business"
logic in there, and compile out a small but necessary tidbit which made
their program function.
--- From my very rough understanding after reading the Lazy Evaluation
article on "d-programming-language.org", this can be possible with the
current std.log interface:
Sample pseudo-code:
logInfo({
auto msg = "Video modes found: ";
foreach( mode, videoModes )
{
msg ~= to!string( mode.width ) ~ "x" ~ to!string(
mode.height ) ~ ";";
}
return msg
});
--- log4cxx simply allows a query to the logger at run-time to find out
the current log level.
I can provide success stories (well, success in finding and debugging
issues) from having a few of these features in our logging library, but
that could be boring so I'll hold back (available on request).
3. Suggestions
Well, the suggestions for std.log are basically the features described
above :-) . It'd be an injustice to express a desire to recreate
log4cxx/log4j in D, but certain features which log4cxx provides greatly
enhance development on large teams.
I haven't thought through it, but I get the feeling D might accommodate
creating the logger hierarchy at compile time, or rather avoid string
(logger name) computations at run-time (log4cxx does all the string
manipulation at run-time).
I hopefully have made a case for including these features. I believe
they'd be helpful to larger teams and teams supporting somewhat complex
commercial products.
I'm aware that it's very easy to ask for things when I'm not the one
working to help provide them. Since I'd like to see this and other
growth in the D language, I'll offer my help however I can.
Thanks,
Gary
