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
