Early review of std.logger

[Sönke Ludwig]

Am 15.10.2013 10:41, schrieb Robert Schadek:
> On 10/15/2013 02:44 AM, Kapps wrote:
>> The simple act of logging a message is very verbose right now:
>> log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
>> prefer something like log.trace("Creating new pool") and log("Creating
>> new pool") where the latter would use opCall to forward to the default
>> log level. If it's intentional that you can assign the result of log,
>> this also helps that because log = new StdIOLogger would be possible
>> (log being a property that returns a Logger, and so a setter could be
>> made), but log("Creating new pool") = new StdIOLogger() would not be.
> The LogLevel is optional. And always writing log.trace might become more
> typing work and assigning a LogLevel and than calling log("..."). Both
> have pros and cons

What happens when a called function alters the default log level?

---
void func1() {
	log.logLevel = LogLevel.debug;
	log("This is a debug message");
	func2();
	log("This is supposed to be a debug message");
}

void func2() {
	log.logLevel = LogLevel.warning;
	log("This is a warning");
}
---


I don't think it's a good idea to use such kind of global state, 
especially for a logging framework that is supposed to be shared between 
libraries, so that it is difficult to predict what a particular function 
does. With a logger that is shared between threads, things get worse of 
course.

A related question: It seems like Logger.logLevel at the same time means 
the minimum log level that is output and the default log level, is that 
right?