Implementing std.log

[Jacob Carlborg]

On 2011-05-16 01:27, Jonathan M Davis wrote:
> 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

I agree with Jonathan, if glog is good enough we can follow its design 
but if it isn't, we shouldn't hesitate to make some design changes.

The approach I take when designing an API for a library I'm writing I 
look at the API of several other libraries that does the same thing. 
Then I try to take the best parts and the parts I like of each library 
and combine them into something that make sense.

-- 
/Jacob Carlborg