Another Log implementation

[Andrei Alexandrescu]

On 05/28/2011 10:08 AM, Vincent wrote:
> Hello, guys!
> I see a lot of discussions about std.Log implementation, that I couldn't
> pass along. I use logs a long time, but some ideas of opponents looks to
> me obscure.
> Of course, different commands have different requirements, but I think
> that such DUMB AND SIMPLE task as logging should not transform to 'one
> fits all' dump of monster classes.

I salute the attitude and approach that simple things should be kept 
simple. Forgetting about it is what spoils logging frameworks like log4j 
and pantheios.

> Logging must conform most commonly used usages, all other 'features' is
> the pain of 'offbeat' developers. Also my 'fresh look' at 'verbosity':
> this is obsolete point of programmers from 70-th. Modern development has
> no time for 'verbosity' like this:
>
> log(Verbosity1, "var i greater than zero")
> log(Verbosity2, "var i is "~ to!string(i))
> ...etc...

Verbosity is not very often used indeed but I'd guess many people got 
used to it because it's present in most libraries. What I do see 
enjoying usage is the notion of severity levels.

> My second point is that libraries must benefit from used language, what
> leads to the third point: logging from other languages(libraries) must
> be used only as an 'idea source', since their logging based on
> capabilities of _their_ languages.
>
> In this light I made this draft for logging, may be it'll cold/delight
> people with its simplicity.
> Let's start from usage:
[snip]

In many ways logging is the "hello, world" of library design so it is a 
very popular topic. There are many possible approaches that are 
difficult to compare. At one extreme we have people who can't even 
fathom the notion: "Here's my logging library: it's called writeln". At 
the other extreme we have monsters like pantheios (88KLOC).

That being said, simple should be not confused with simplistic. An 
informal logging discipline based on writeln is practically 
inconceivable for systematic use by a team larger than a couple of 
persons (as everyone will choose their own format, place to log to, 
notion of severity and verboseness etc). Furthermore, a logging library 
with a "simple" implementation is not necessarily "simple" because it 
may actually complicate matters for its client, sometimes in surprising 
ways. In detail (I'm talking about the sketch at 
http://pastebin.com/WwkrD02g):

* The library doesn't take care of capturing the origin of the log 
(file/module/line) so the user must pass them manually.

* The library requires version(logging) to control enabling. Essentially 
the client would need to prefix _all_ logging lines with 
version(logging) in order to benefit of compile-time configurability. 
This is verbosity pushed onto the user, not confined to the library.

* The library always evaluates arguments, even when logging is 
dynamically disabled. This makes the library unnecessarily slow. (The 
mechanism of generating one new string from a template with each call is 
also slow, but that can be fixed modularly.)

* The library does not define a notion of a severity hierarchy, leaving 
it to the user to define one. But the absence of such a hierarchy also 
means there is no library-level notion thereof, which means the user 
must take care of enabling and disabling e.g. the info level when the 
error level is disabled. Arguably defining a hierarchy could be 
considered outside the scope of a "core" logging library, but that means 
more work for the casual user of the library to achieve a common task.

Improving on such issues is possible but inevitably the simplicity of 
the implementation erodes, to the point that all logging libraries that 
have a minimum of reasonable features have the "same" complexity, with 
some wiggle room given by implementation particulars. So the real trick 
is to know where the feature list must stop. Without claiming to be 
exactly right, I believe yours stops too early and pantheios stops too 
late. Also without claiming to be right, although I find it entirely 
explainable that everyone believes they can write the perfect logging 
library (unlike everybody else), I believe something close to Jose's 
library (after community feedback) will become the standard library for 
logging, so we should at best we consolidate efforts behind it.


Thanks,

Andrei