Review of Jose Armando Garcia Sancio's std.log

[James Miller]

On 14 February 2012 10:17, Sönke Ludwig
<ludwig at informatik.uni-luebeck.de> wrote:
> Log levels "debug" and maybe also "trace" would be useful, but I see that
> vlog(n)() is meant for that purpose. I would just prefer explicit names
> instead of just numbers.
>
> Is there a compelling reason why formatted logging is not the default? I
> find that most logging calls in practice use formatted output, and the only
> overhead would be searching once through the format string in the case of
> format placeholders.
>
> A predefined logger for OutputDebugString on Windows would be useful - or
> maybe it could be used instead of stdout at least for non-console
> applications.
>
> One kind of log writer that I have in my code is one that outputs a nicely
> formatted HTML file with built-in JavaScript to be able to filter messages
> by priority or module. Maybe this is too much for a standard library
> implementation though.
>
> Support for multiple log writers can be useful (e.g. logging to a file +
> logging to stdout or to a log control inside of the running application). Of
> course, one can also simply write a "MultiDispatchLogger"...
>
> A format option to log the thread name instead of just the ID.

I agree that there needs to be an easy to use format-based logger,
even if its just logf template that calls format on the filter, since
writing `log!(info).format("my string %s", s);` looks bad compared to
`logf!info("my string %s", s);`

Looking through the docs, there needs to be a better indication of
configuration in the primary example, since you don't even mention it,
I thought it might not exist.

A built-in console logger should probably be available, one that
writes to stdout at the very least, since I often need log messages
for debugging, other loggers can be build on top of the Logger
interface, separate from the library, but I imagine that many people
would want a console logger and doing it in the standard library will
prevent too much repeated work. It would also be an idea to make it
the default, but at this point I can't really separate out my
practices from what I think most people do.

A debug-level log would be nice, but I don't really care either way.

A built-in MultiDispatchLogger (or similar) would be nice, but I don't
think it really matters.

Otherwise, I think it all looks good; fairly simple to use and
configure, ability to override the defaults if needed, ability to swap
out backends at runtime. The docs need work, but docs always need work
:P.

It might not mean much, but this gets my approval.

James Miller