Review: std.logger

[Andrei Alexandrescu via Digitalmars-d]

On 7/24/14, 12:23 PM, Robert burner Schadek wrote:
> On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu wrote:
>> log(A...)(lazy A stuff); // just log whatevs
>> log(A...)(LogLevel lvl, lazy A stuff); // log at specified level
>> log(A...)(bool c, LogLevel lvl, lazy A stuff); // conditionally log at
>> specified level
>
> log(A...)(lazy A stuff) matches the next two sigs as well. I tried that.
> Maybe some overloading inside the function body may work, but that is
> just a mess IMo.

Use template constraints.

I realized after posting that the log level should also be a static 
parameter so the logging framework can choose to disable it entirely:

log!Loglevel.info("crap");

But wait there are the explicit functions trace, error etc. so... those 
do implicitly choose the level statically. Noice.

>> There's no conditional logging without specifying a level, which
>> should be fine seeing as conditional logging is not that frequent to
>> start with.
>
> there is. tracec, infoc, ....

I meant in the proposed design.

>> There should be some shortcuts for logging levels such that one can
>> write log(info, "crap") instead of log(LogLevel.info, "crap").
>
>
> there is trace%s, info%s, warning%s .... c|f

Okay.

>> 3. I'm not sure I like the design using defaultLogger in conjunction
>> with free functions using it. It clearly makes for comfortable casual
>> logging by just calling log(whatevs) and it uses a precedent set by
>> stdout. But I wonder if it would be cleaner to just give it a shorter
>> name "log" and then have it have a "write" method:
>>
>> log("crap");
>> -> becomes ->
>> log.write("crap");
>>
>> Also there'd be log.writef("%s", "crap") etc.
>
> well, this is by design. I wanted to provide very easy simple looging
> for hacking a small script. If you want more, you properly want to
> handle Loggers as variables.

I think I'm fine with that after all.

>> 5. There was some nice stuff in the previous std.logger work by me and
>> later Jose (I think), which allowed logging every n times/milliseconds
>> so as to allow nice throttling. That's nice to omit/defer for
>> simplification purposes, but I noticed that log noise is a serious
>> matter.
>
> I could start std.logger.condition

Thing is you must make sure you integrate with statically setting the 
logging level. Throttling is _especially_ used/useful in intensive 
loops. Being able to rebuild a large app with a different logging level 
to debug a pernicious condition at the cost of some speed is pretty 
awesome. It also makes verbose logging psychologically "free" the same 
way assert is.

In fact you may want to define an extra logging level e.g. "verbose" or 
"yap" which is by default disabled and can be enabled explicitly. It 
would be hierarchically below normal logging.

>> 6. The current backend design requires use of classes and references,
>> i.e. garbage collection. Amid the current tendency to make std work
>> without requiring GC, I think a design based on RefCounted would be
>> recommended here.
>
> Maybe I'm wrong, but RefCounted does not support polymorphism and that
> would break not only the MultiLogger and the defaultLogger. I think this
> is a legitimate use of classes, as Logger properly stay alive the
> complete run of the program.

The use of polymorphism is legit. RefCounted either works with classes 
or must be made to work with classes.

>> 7. The current backend design fills a struct with data then passes it
>> to the implementation. But if the implementation doesn't use e.g. the
>> timestamp then that work has been wasted. Maybe offer the fields as
>> properties instead, with caching upon first use?
>
> hm, but taking the timestamp after the log call seams wrong. Again, I
> think this is by design from using polymorphism.

Yah, it'd be a tad later but I guess it shouldn't be a large problem. 
Same goes about the thread id.

>> 8. Documentation needs work as it has disfluencies and typos.
>
> If have already worked in all of JakovOvrum and you fixes.

Cool, thanks.



Andrei