Early review of std.logger

[SomeDude]

On Thursday, 17 October 2013 at 07:34:28 UTC, qznc wrote:
> On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton 
> wrote:
>> The strength of this is that it would allow us to freely 
>> integrate D libraries that use std.logger, yet filter their 
>> log output from *outside* the library through the std.logger 
>> API.
>
> This is one of the most important aspects in my opinion.
> Std.logger should be easy to use, so library writers are
> encouraged to use it. Compare this with the "unittest" keyword,
> which makes it easy to write some simple tests. Of course,
> flexibility to use complex machinery for using the 
> messages/tests
> is necessary. Just like we can hook up more advanced unit 
> testing
> frameworks, we should be able to hook up more advanced logging
> machinery. The advanced stuff is not for Phobos though. Advanced
> stuff for unittests is for example, parallel execution and
> graphical reports. Advanced stuff for logging is for example log
> rotation and networking.

There is no contradiction. Complex log libraries become 
(relatively) complex when one wants to use their advanced 
features, but are as simple as the others when one wants to use 
them simply.
That's why in the Java world nearly everyone uses Log4j instead 
of the official JEE API.

In practive, you really want a powerful logging facility.
Another feature I used once in a project, was to log to RAM. We 
decided to log TRACE logs in production in order to catch a rare 
bug, but of course, it would output too many logs. So we decided 
to log everything in RAM and keep the last 1000 logs. Whenever 
there would be an exception or a CRITICAL log, the whole 1000 
logs would be dumped on disk. That feature proved very useful.