std.experimental.logger formal review round 3

[Kevin Lamonte via Digitalmars-d]

On Saturday, 25 October 2014 at 16:43:10 UTC, Dicebot wrote:
> However, I don't think any of those are truly critical and this 
> proposal has been hanging there for just too long. In my 
> opinion it will be more efficient to resolve any remainining 
> issues in follow-up pull requests on case by case basis then 
> forcing Robert to do it himself - there will be some time left 
> before next release to break a thing or two before public 
> statement is made.

(Am I a voter?  No idea.  But here is my feedback, based on my 
recent experience implementing a fuller backend for std.logger.)

I agree, I think std.logger is ready to go forward and needs to 
get into end-user hands.

I see four areas that are incomplete but SHOULD be deferred to 
future bug reports / enhancement requests:

1. Additional LogEntry fields: Thread, Fiber, Throwable, maybe 
others.  These should only be adopted if the end users can 
provide a compelling case for why their Logger subclasses (or 
backend framework) can't give them what they want.

2. Additional Logger functions: caught(), throwing(), maybe 
others.  These should be driven by the needs of phobos' use of 
std.logger.  (And phobos SHOULD use std.logger and eat its own 
dog food.)

3. Modification of the order or method in which the Logger 
functions obtain their data in constructing the LogEntry, i.e. 
call Clock.currTime() differently or not at all.  These should be 
controlled by future additional fields/flags in Logger, with no 
changes to the functions one calls on a Logger.

4. Control of logging across multiple libraries/applications.  
This should absolutely be deferred until phobos itself starts 
using std.logger.

Of these issues, I think that #4 is a huge can of worms that is 
impossible to make everyone happy, and we keep poking into it as 
a result of not accepting that the only people who can decide on 
it are the application writers, not the language and phobos 
designers.  The two solutions for it at the extremes are:

A) Deciding if a Logger is enabled when it is obtained by the 
client (via a Logger.getLogger() factory function), which 
requires imposing a namespace of some kind that ALL future 
libraries will have to adhere to.  Note that log4j -- currently 
the fastest and "biggest" logging system out there -- started 
with a fixed className namespace, but moved away from that later 
on to more general user-defined "categories".  Even in a 
straightjacketed language like Java one namespace isn't good 
enough.

B) Deciding if a Logger should emit (based on end-user decision 
via config file, environment variable, ...) at the 
Logger.writeLogEntry() call via filtering on the LogEntry fields.

Option A is cumbersome in client code but very fast in practice 
because getLogger() can set the Logger's logLevel to filter 
messages before the logImpl() call.  Option B is easier in client 
code (and also lets many functions/modules/libraries write to a 
single Logger ala stdlog) but very slow at runtime because the 
namespace filtering can't occur until after the LogEntry is fully 
formed (formatted (including allocation) + Clock.currTime + ...).

The application writers are the only people in a position to 
choose which end of this tradeoff makes the most sense for them.  
Phobos will have to choose for itself someday, and I think that 
various subsystems may very well choose differently based on 
their most common usage.  std.net.curl might choose option B 
(just logging to stdlog) because it's got this nice 
clearly-defined border between the client and libcurl; whereas 
std.range might go for option A (letting the users set a 
getLogger() delegate) because it is very cross-cutting and users 
will only want to see log entries when doing range stuff in their 
code and not all over phobos or other libraries.