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!
