On 12/4/14 8:16 PM, Martin Nowak wrote:
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg wrote:
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine grained control over log levels (per module/package)
- zero overhead for statically disabled log levels
- zero (almost) boilerplate (works even with the global stdlog)
- and it establishes a nice convention to enable logging for a library
`pkg.logLevel = LogLevel.info;`
This is kind of cool that you can do in D, but it feels like a hack. I
have stopped following the std.log thread, could you summarize what
issues you're having and trying to solve and why not a more obvious
solution doesn't work?
Zero overhead for statically disabled log levels.
The current proposal uses global version identifiers to alter the
behavior of std.logger.
Fine grained (at least per library) control over log levels.
The current proposal required to use different logger wrappers in each
library and scoped global version identifiers, see [1] in the OP.
We should scrutinize and streamline this idiom properly. It's very
powerful and after enshrined in Phobos it will serve everyone as a
precedent to follow. Thanks, Martin! -- Andrei
