LogLevel [was std.experimental.logger formal review round 3]

Martin Nowak via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 4 02:16:51 PST 2014


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.


More information about the Digitalmars-d mailing list