std.logger

[Piotr Szturmaj]

W dniu 23.08.2013 14:16, Robert Schadek pisze:
> On 08/23/2013 01:10 PM, Piotr Szturmaj wrote:
>> 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("...");
> the default logger is not shared. so no thread problems.

But the problems remain with non-default loggers?

>>
>> 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.
>
> auto myLogger = new MyLogger(myLogLevel);
> mylogger("my log msg");

So, we're at the start point. You must either create instances for every 
log level (and for every logger class) or set a log level before calling 
the log() - and this is not thread safe for custom loggers.

This also doesn't look as a good design:

auto myLogger = new MyLogger(myLogLevel);
myLogger("my log msg");
myLogger.logLevel = anotherMyLogLevel;
myLogger("another log msg");
myLogger.logLevel = yetAnotherMyLogLevel;
myLogger("yet another log msg");

Why encapsulate a logLevel which is immediately used in the function? 
Why store it in a class? It should be a function parameter instead.

Don't get me wrong. I just want to help you.

I think that default logger concept should be separated to default 
logger and default log level (default log level should be independent 
from default logger)

>>
>>>>
>>>> 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.
> You can implement the abstract logger class and create new log
> functions, but the design is intended to simple and user defined log
> level makes it complex.
>