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.
