Implementing std.log

[Jonathan M Davis]

On 2011-05-15 16:01, Andrei Alexandrescu wrote:
> On 05/15/2011 10:26 AM, Jacob Carlborg wrote:
> > On 2011-05-15 00:33, Andrei Alexandrescu wrote:
> >> On 05/14/2011 05:17 PM, Jonathan M Davis wrote:
> >>> On 2011-05-14 14:56, Michel Fortin wrote:
> >>>> On 2011-05-14 17:31:30 -0400, Jonathan M Davis<jmdavisProg at gmx.com>
> >>>> 
> >>>> said:
> >>>>> So, I do think that knowing which thread is logging what could be
> >>>>> very important for some programs, but I don't think that separating
> >>>>> the log files is necessarily a good idea. If you did, you'd lose
> >>>>> timing information (unless the time is at the beginning of every log
> >>>>> line (which could also be useful), but then you'd have to read the
> >>>>> times and
> >>>>> compare them to see what happened before what). So, I'd be all for
> >>>>> some
> >>>>> options and extra information which could be added to each log line
> >>>>> which would help debugging, but I don't think that thread-local
> >>>>> logs is
> >>>>> a great idea.
> >>>> 
> >>>> I'd even go further and question whether it makes sense to have info,
> >>>> warning, and errors be written to separate files.
> >>> 
> >>> I'd definitely vote for them all to be in the same file, but I don't
> >>> generally
> >>> see much benefit in having multiple log files. I like having them all
> >>> in one
> >>> place where you can see what happened in what order. Having them in
> >>> separate
> >>> log files is just going to make it harder to figure out what happened,
> >>> and I
> >>> think that it would become tempting (for me at least) to just log
> >>> everything
> >>> at exactly the same level so that they ended up in the same file.
> >> 
> >> The info log contains log messages for all levels.
> >> 
> >> Generally I'd want to stray from glog's major design decision as little
> >> as possible. It's an approach validated by years of experience in
> >> heavy-duty applications. Also, people coming from glog and used to its
> >> features would find it unpleasant that we decided to do things a
> >> different way without solid reasons.
> >> 
> >> 
> >> Andrei
> > 
> > Why not? It doesn't say anywhere in the documentation, as far as I can
> > see, that it's based on glog.
> 
> That's beside the point as the documentation could and should be
> changed. I've said repeatedly it's based on glog, and I think it's a
> good thing.
> 
> > I think that, in general, that is a poor
> > argument: "Because library A does it like that we also have to do it
> > like that". What about all people coming from library B, C, D and so on,
> > it will be unpleasant for those as well because we didn't follow their
> > particular library design.
> 
> It's a good argument if library A is considered better by the person
> making the argument than B, C, and D. One thing is that glog has most
> desirable qualities I am looking for in a logging library: allows
> compile-time and run-time enabling/disabling, it's relatively small,
> it's simple, it's effective, and is widely used. I'm sure there are
> other libraries that score better on either dimension, but not on all.
> 
> There are two departures I chose to make from glog: (a) I added the
> critical log which throws an exceptions (Google wouldn't need one
> because they don't use exceptions), and (b) I replaced the clunky
> LOG_IF_EVERY_N etc. with the flexible when(), every(), after() etc. I
> think these are well justified choices.

I think that it makes good sense to start with an API based on an existing API 
which is known and heavily used and then adjust it as appropriate to our 
needs. In doing so, we might as well leave it the same as the original where 
we don't need to change it, since there is some gain for those familiar with 
the original. However, the real question then is where it does and doesn't 
make sense to change it. If enough people agree with Andrei on those 
decisions, then it will likely become std.log. However, if there's enough 
disagreement, and we can't reach an appropriate compromise on such changes, 
then it likely won't become std.log.

Hopefully we can come a solid design based on glog with whatever changes we 
actually need without having to drastically change what it does in comparison 
to glog. That would be ideal. However, I also think that if it really looks 
like the general consensus is against something about how glog does things, we 
shouldn't be married to how glog works. So, overall, I agree with Andrei. The 
devil is the details, however.

- Jonathan M Davis