Another Log implementation

[Vincent]

Hello, Andrei! Very appreciate you spent time on my work.
I agree with some your critique, sure it's just a question of  
improvements. My main question is acceptance of my log library as a whole  
conception, since it's simple and 10 from 10 programmers can understand  
its sources (I keep it as very serious goal).
Let's discuss doubtful points...

> Verbosity is not very often used indeed but I'd guess many people got  
> used to it because it's present in most libraries.

Habit is not the rule. You must remember those days when every DOS editor  
show time in menu bar. WHY? Just because everybody did it. I see nothing  
bad to loose this 'verbosity' as archaic feature.
As I said before, 'special demands' is the pain of 'special programmers' -  
if they REALLY cannot live w/o 'verbosity', they can add it in 3 LOC.

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

I've read posts related __LINE__s in log and don't see any reason in this  
feature. Why?
1. It's not direct task of 'logging'. Log doesn't care about your  
lines/files just because you're too negligent to control what and where  
you log - its task is just assemble together runtime info.
2. Nobody prevent you from doing it! Just make 'mixin' with __FILE__ and  
use.
3. In my practice I didn't see so low-level approach for debugging - well  
organised log shows enough, why people care about number of code line in  
editor?? Funny, heh...
4. Logging is not only "We have a problem in line 10!" - it's "trace of  
life" for our program.


> * The library requires version(logging) to control enabling. Essentially  
> the client would need to prefix _all_ logging lines

Agree completely. But something says to me that it's just a my little  
knowledge of D (and it's true). Sure there is some feature to make log  
calls 'invisible' without 'version' prefix - I just used feature I sure  
about. May be mixins will help? This is the place where I need help of  
community.

> * The library always evaluates arguments, even when logging is  
> dynamically disabled.

First, let's remember Knuth's "Premature Optimization" warning - say "it's  
slow" only when it's really slow down your program.
Second, remember use case of this "runtime switch": "ALL logging is  
enabled (read "everywhere it's slow"), but at this place it's disabled  
(and who cares how slow it is?)".
Third, if you use log, you NEED this info, despite how fast it was  
calculated. And even if you jump over with 'lazy' arguments, they HAVE to  
be calculated - you wait 'em anyway! So... what a benefit you have from  
laziness?
And hell, if you're good programmer, you'll never write critical section  
like
log("a");
log("b");
...rather you accumulate log info and output it at once.
I agree with usefullness of 'lazy' stuff, but not in this case.


> * The library does not define a notion of a severity hierarchy

If you look at use cases of this 'severity', there is no 'hierarchy' (look  
at usage of my library) - it's again "habits" of 70-th. Just obvious  
example from real life:
I log all 'info' messages about client actions. But somewhere I get  
database exception - my fault, logged as 'critical'. Together with two  
levels above I have 'warning' level about problems like 'this person has  
no surname'. Question is: "Why I must dig in 'warning' trash, when I just  
need info what client did and which critical problem happen?". As you see,  
'hierarchy' is just "flat" view on problem - there is independed  
severities and _combination_ of 'em.
Again, no apocalypse happen - who need this feature, that must spent time  
on it.


> 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.

Exactly. You cannot include in simple 'string assembler' all functionality  
(esp. legacy point of view - time is changed!). Simple requirements must  
lead to simple usage - if you don't use 'verbosity', why you should pass  
parameters in every log call?


> 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.

What if I don't believe? :) We'll spent time on functions, used by 1% of  
'old shoes' and give a bad example for next generations. I don't pretend I  
wrote the best library ever, but I kept on rule 'implement only necessary  
stuff' and I have a reason for every decision.
Well, I don't want to press anybody, but before you completely give up my  
implementation I wanna be smashed with serious arguments how bad my design  
is. :) (may be it'll be good lesson for another designs!)

Good luck for all community!