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
