On Mon, 13 Feb 2012 10:50:04 -0500, David Nadlinger <s...@klickverbot.at>
wrote:
There are several modules in the review queue right now, and to get
things going, I have volunteered to manage the review of Jose's std.log
proposal. Barring any objections, the review period starts now and ends
in three weeks, on March 6th, followed by a week of voting.
Some notes:
I dislike that logging affects function execution. In particular, I don't
think the logging library should have any business throwing exceptions or
errors. It should be invisible to the application. The equivalent
function can be had by giving a wrapper function (i.e. log this message at
the fatal level, and then throw an error). A use case I can see is
printing several fatal log messages before exiting.
The log aliases use names that are too common. I think log.info is a
better symbol for logging than just 'info', which could be a symbol in a
myriad of places. Given that D's symbol lookup rules allow shadowing of
global symbols, this does not work out very well.
Like others have stated, I think vlog is a) confusing, and b)
unnecessary. Even reading the docs, I can't understand what it's used
for, and why it has such different syntax than the normal logging stuff.
I really like the every function, that's a great idea, one that I've
manually implemented (at least the once every N times) many times.
Do we have to make the logger a singleton? I'd like to see cases where I
can have different log instances. For example, an instance I can
enable/disable per class type, or an instance that logs to a diffferent
backend. Or a non-shared instance which does not need to handle threading
issues (i.e. a per-thread file log). Does this help with the vlog issue?
-Steve
