Review of Jose Armando Garcia Sancio's std.log

Sönke Ludwig ludwig at
Thu Feb 16 01:57:11 PST 2012

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

More information about the Digitalmars-d mailing list