Another Log implementation

[Vincent]

On Mon, 30 May 2011 01:13:13 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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...