Am 16.02.2012 10:21, schrieb Jonathan M Davis:
On Monday, February 13, 2012 16:50:04 David Nadlinger wrote:
Please post all feedback in this thread, and remember: Although
comprehensive reviews are obviously appreciated, short comments are very
welcome as well!
Why does vlog even exist? It's a needless complication IMHO. Let the log
levels manage what does and doesn't get logged. I see no reason to add the
concept of verbosity on top of that. It's a needless complication.
Also, _please_ add a debug level. Personally, I'd argue for simply copying
syslog's levels and matching them, since ideally any logging on Linux would be
going to syslog anyway. But there are good reasons to have messages beyond
info. I sure wouldn't want _all_ messages which don't indicate a problem in
the app to be marked as info. For instance, what if I want to have info
displayed in release mode but want greater verbosity in debug mode? I'd need
another log level which isn't there. Using the concept of verbosity to try and
handle this is a needless complication. syslog has
#define LOG_EMERG 0 /* system is unusable */
#define LOG_ALERT 1 /* action must be taken immediately */
#define LOG_CRIT 2 /* critical conditions */
#define LOG_ERR 3 /* error conditions */
#define LOG_WARNING 4 /* warning conditions */
#define LOG_NOTICE 5 /* normal but significant condition */
#define LOG_INFO 6 /* informational */
#define LOG_DEBUG 7 /* debug-level messages */
And I'd like to at least see notice and debug added.
Well in addition to Debug I would also like to see Trace but it's f. ex.
hard for me to tell the difference between Info and Notice and their
names do not imply that certain severity order IMO. So I see a point in
the argument that vlog() allows everyone to be happy without endless
numbers of predefined log levels.. however I'm also not quite convinced.
While we're at it, what's the point of dfatal? Why on earth would a _fatal_
condition not be fatal if it were in release mode if it were fatal in debug
mode? Is it fatal or not? It seems to me like another needless complication.
If you're going to have write, then have writef, not format. Then it's
actually consistent with our normal I/O functions. Also, do writef and format
automatically append a newline? If so, then they should be writeln and
writefln.
I think the names should be as short as possible for the common 99%
case. As this is not a general purpose stream, I think it is fine to
drop the 'ln'. And the current version that defines info("") as the
version that can format and info.write("") as the plain string version
seems to be quite optimal in this regard.
In my optinion, more descriptive names would just impair readability
here instead of helping. They will be written endless number of times
but do not influence the program flow and should immediately
understandable by anyone who sees them. But something like
log.warn/logf.warn or log.warn/log.warnf might also work if you really
want the consistency...
Rich is a horrible name IMHO. It says nothing about what it actually is or
does. I'm not sure what a good name would be (BoolMessage?, LogResult?), but
Rich by itself is very confusing and utterly uninformative.
And why does Configuration's logger property throw if you set it after a
logging call has been made. Is it really that inconceivable that someone would
swap out loggers at runtime? Or is the idea that you'd swap out the
Configuration?
- Jonathan M Davis
