Another Log implementation

Vincent thornik at gmail.com
Mon May 30 03:13:47 PDT 2011


On Mon, 30 May 2011 02:58:00 +0200, Jose Armando Garcia  
<jsancio at gmail.com> wrote:

> Why is verbosity not useful?

Probably, because it's too expensive? :)

> You just remember that the developer that wrote the IO layer was nice
> enough to log all IO inputs at verbosity level 3.

OK, but saying this you assume we also have level 1 and 2! Can you give an  
example how your code will look with ALL these levels implemented?
I fear on 3 LOC you'll have 10 lines just to provide 'verbosity' logic.  
This is why it's expensive.
Problem is not only in digits - HOW you'll decide how many levels to have  
and what to show on every level? Don't you scared for your head if it's 1M  
LOC app? :)

I can say more: looking at program trace I more interested not in 'give me  
more details', but 'give me details on this object'. In your case
it's IO object - turning ON verbosity, you do it for ALL logging, while  
you need just an IO module. What you say on this? :)
In this case I prefer snippets like this:

// some IO logic
version(log_io) logDbg(`SENT: ` ~ line);

It allows to see only what you need and I don't give a damn if it's longer  
for two words.

Jose, just take it right: long term log libraries are OK  
_for_people_who_use_it_. But I see no any reason to copy again and again  
old-time solutions - features are not only accumulated, but outdated too  
(this is why you are with D, not C :) ). So I want 'clean up' old stuff  
and implement just really necessary capabilities (Which Andrei named as  
"simple streaming" :) ). Before you(we) implement something, don't think  
"Oh, we have verbosity and we can use it like this!" - start from GOAL:  
"We have this task, how it can be implemented?" - sure, from this point  
you never even think about 'verbosities' (depends from mind, OK).
Well, since people are conservative, I don't expect too much attention,  
but anyway thanks you read my ideas - hope it help.


More information about the Digitalmars-d mailing list