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

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 4 06:32:44 PST 2014


"Martin Nowak"  wrote in message news:m5ocaj$2i8t$1 at digitalmars.com...

> 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;`
>
> Basically it works by declaring a logLevel in a module or package.
> Then the std.logger module does a reverse lookup of that declaration.

FWIW I don't really like this - it feels like a hack.  I'd rather just 
declare a private logger alias (or something like that) and use that in the 
library.  Decision can be made at compile time, doesn't require reverse 
module imports, doesn't depend on global versions.

eg

alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); 



More information about the Digitalmars-d mailing list