std.logger

[Piotr Szturmaj]

W dniu 23.08.2013 11:01, Robert Schadek pisze:
> On 08/23/2013 10:30 AM, Piotr Szturmaj wrote:
>>>> ?
>>> Any other Logger:
>>> auto myCoolLogger = new XXXXLogger();
>>> myCoolLogger.logLevel = LogLevel.Critical;
>>>
>>>
>>> For the default Logger:
>>> log.logLevel = LogLevel.Info;
>>
>> I see, but isn't separate class instance for every log level a bit too
>> much? Setting log level before calling log() isn't (IMHO) good either
>> (think of multi-threaded logging).
> There isn't. Every Logger has a LogLevel, which can be changed. Every
> log message also has a LogLevel hence .info() .error() ...
>>
>> My opinion is that LogLevel should not be encapsulated within Logger
>> class.
>>
>> Instead function overloading should be used (again IMO):
>>
>> void log(string message);
>> void log(LogLevel level, string message);
>>
>> So having separate classes for different loggers (sinks) is very nice,
>> but LogLevel should be specifiable for each message, no matter which
>> Logger class is used.
> It is.

so if I have a LogLevel variable I want to use:

LogLevel myLogLevel;

I need to write this:

# alternative 1 (possibly wrapped in a function)
switch (myLogLevel)
{
     case LogLevel.Info: log.Info("..."); break;
     case LogLevel.Warning: log.Warning("..."); break;
     case LogLevel.Error: log.Error("..."); break;
     case LogLevel.Critical: log.Critical("..."); break;
     case LogLevel.Fatal: log.Fatal("..."); break;
}

#alternative 2
log.logLevel = myLogLevel; // not thread-safe (shared state)
log("...");

I mean sure, it is possible to specify LogLevel for each message, but 
only at compile time (by the use of function names .Info, .Error, etc.).

This is not what I meant in my previous post. I rather meant the ability 
to specify LogLevel using a runtime variable.

>>
>> Then, each _compile-time_ specifiers like .Warning() or .Error()
>> should be just a syntactic sugar over log().
>

Just thought that the ability to add user defined log levels may be 
useful too.