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

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 8 13:19:30 PST 2014


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



More information about the Digitalmars-d mailing list