std.experimental.logger formal review round 3

[Kevin Lamonte via Digitalmars-d]

On Tuesday, 28 October 2014 at 11:11:09 UTC, Martin Nowak wrote:
> I think part of the misunderstanding is that I'm thinking of an 
> app as user code plus a number of libraries all on top of 
> phobos. Say I have an app using vibe.d and I want to enable 
> logging in my app, but disable it in phobos.
> Was it even a design goal that logging can be enabled on a per 
> library level?

Whether it was an original design goal or not, I don't think it 
can be done with today's std.logger, and I would argue that it 
should not be a function of std.logger at all.

Selective logging of a mix of libraries requires a namespace to 
identify each library, along with a method for libraries to 
obtain their Loggers based on that namespace (e.g. giving Logger 
a name, which it does not have now, and using a factory method 
like Logger.getLogger()).  We could assume that module names will 
always be available to do that job (and by default I do provide 
that as a reasonable default in log4d), but I can easily imagine 
other namespace choices for unknown future users.  I also think 
that most end users would prefer their selective 
enabling/disabling of libraries' logging to happen at runtime, 
not compile time, and the HOW of turning things on/off will also 
be very user-dependent (regex, config file, environment var, ...).

We are bleeding between "mechanism" and "policy" here.  I feel 
that std.logger is mechanism: given that a client has a Logger 
"thing" (struct, class, whatever), which methods will the client 
call on it to emit output to somewhere?  Frameworks like log4d 
are policy: how are the Loggers that are obtained by lots of 
clients organized into a coherent whole, and the outputs 
filtered/directed/controlled by the final end-user?  Policy 
should always be deferred to third party libraries.  I obviously 
like the log4d/log4j approach, but other people will like vibe.d 
logger, some will roll-your-own, some will just send everything 
to syslog, etc.

If we really want to insist that std.logger provides selective 
control of libraries, then I think we will also need to establish 
policy at this time.  I see two reasonable choices.

Option 1:  minimal change

1. The policy is that we control library logging by letting the 
client replace Logger references at runtime.
2. We say that libraries either use stdlog, i.e. info(...), 
error(...), etc., OR that they expose a Logger reference that 
clients can replace.
3. Clients replace stdlog or the libraries' Loggers with Loggers 
from their chosen framework.

Option 2:  invasive change

1. We make policy that there is a namespace of all loggers and it 
is __MODULE__.
2. stdlog is removed.
3. Loggers are obtained only via a getLogger() type call.  Any 
function that wants to log must call getLogger() first.
4. log(...), info(...), etc. are removed.  All logging goes 
through a Logger: Logger.info/error/etc(...)
5. Clients replace the getLogger() factory method with a 
function/delegate provided by their framework.

I think that option 1 would scale better long-term.  Phobos can 
choose to use stdlog for its own logging, and other libraries can 
make their own (vibelog, foolog, ...).  std.logger would need no 
changes.



Final thought: filtering.  We have several filtering methods now, 
and I am confused as to what is actually missing:

* ANY AND ALL logging can be disabled at compile time via 
versions.  This only includes client code and libraries the 
client is compiling too; I would assume that the default shipped 
phobos would not version-remove log calls.

* ALL logging can be disabled at runtime via globalLogLevel and a 
single if check at the call site.

* Per-Logger logging can be disabled at runtime via 
Logger.logLevel and a single if check at the call site.

* All other kinds of filtering (on msg, timestamp, method, etc.) 
are available at runtime to Logger subclasses, but happens after 
the logImpl call and setup of LogEntry.

What other capabilities are needed for filtering?