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?
