On Mon, 30 May 2011 01:13:13 +0200, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Without automated headers including location of the log line and
date/time, one can't even call that a logging library.
I repeat: if people so careless that they don't know what and from where
written in their log, lines and files won't help.
EVERY log place must provide high level info, which must be enough for
conclusion. If in 5 places you do
log(`SEND: ` ~ line)
of course your log is dump of useless lines!
Again: nothing prevent you from giving file and line, just include 'em in
message! And log purpose is not only 'now I run line 20 and i = 3' - it
can be log of user actions for manager's report - who cares which
files/lines it involved?
It's an text streaming facility.
It is! Like any GUI library is "just a graphics rectangles to click on". :)
There is not so much 'log specific' stuff, some of 'em is just a
'tradition'. Log is TEXT, which help you to debug code.
Evaluating arguments always vs. not at all is a matter of principles.
Principles are nice in MacDonalds, programming is a bit more complex
stuff, where every principle must be reasonable to apply.
* The library does not define a notion of a severity hierarchy
If you look at use cases of this 'severity', there is no 'hierarchy'
Your example describes a trivial matter. Often times, the trace leading
to a critical problem is indicative of the issue in more complicated
applications.
Sorry, nothing understand what you disagree with. First, I don't decline
'severity' since we can have logWarnings, logErrors, etc.
Second, I just show that 'linear severity levels' helps not so much when
you need selective messages - you cannot skip intermediate levels when you
don't need 'em.
First, this seems to be the third time you are referring negatively
about age.
Surprisingly wrong view. Not age, but OLD LIBRARIES written in 70-th, when
people even didn't mention 'usability', 'maintainability' and other stuff.
Nothing unusual in the fact, that programming practice made outdated some
conceptions. Look at LISP - lispers sh*t with bricks proving how LISP good
is. WHERE is this LISP? In the dustbin of history.
What you found offensive here? Like you name spade as spade, I name old as
old. *amazement*
Design is a subjective endeavor, so you can always make a
counter-argument to pretty much any argument (as you just did).
Disagree. There is good conceptions, which cannot be satisfied with ugly
design: extensibility, scalability, maintenance, robustness, usability ...
Bad design quickly drops under good critique.
I'm happy you found weak places in my draft, but some critique rely just
on your imagination how logging must be used - I cannot see reason to
change library by every subjective demands.
So unless you set out to implement nothing but simple streaming....
Again, it's because of your vision "what logging is". As many messages I
read, same many opinions I met - from ridiculous (to me) __FILES__ and
__LINES__ to "all logging is a file output routines".
Before people touch any library they must create a list of requirements,
discuss it (instead of pointing "oh, in library blah-blah it made like
this - let's do the same!"), test in practice and only after this they may
pretend to be in std.* namespace. I didn't see any discussions except
already done library with automatically generated docs. Nice development,
heh! :) (kill me if I'll try to buy such software)
To be more productive I can formulate my _core_ list, which can be
extended with "bells and whistles", but everybody must understand where is
LOG and where is I LIKE IT.
1. Minimal logging must be as simple as one function call with one string
argument.
2. Log must support multiple destinations of different kind.
3. Destinations must be easy expandable - one simple class for any kind.
4. Enable/Disable log at run/compile time. IDEALLY doesn't consume CPU if
completely disabled.
5. Suppport for different output formats.
That's it! Even handy string formatting is not a requirement - just
because it's a 'sugar', not 'logging' itself.
In my practice I never used anything more complex due to useless of any
other functionality - good log provides enough.
WBR...
