Early review of std.logger

[Sönke Ludwig]

Am 14.10.2013 20:24, schrieb Robert Schadek:
> On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
>> Am 14.10.2013 15:12, schrieb Robert Schadek:
>>> On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
>>>>   - The static methods in LogManager should be made global and the class
>>>>     be removed. It's not for objects so it shouldn't be a class.
>>> LogManager also stores the global log level. Sure I can make another
>>> static global function storing this log level, but I would like to keep
>>> them together as they belong together IMO.
>> The same could be said about the global "log" functions, which are
>> tightly coupled to that state. I think this is already nicely grouped
>> together by the logger module itself, since there is not much else in it.
>>
>> Basically, I just wouldn't consider this style to be particularly
>> idiomatic D code, but of course that's just personal
>> perception/preference (there is also some precedence using "struct"
>> instead of "class" in Druntime). However, if it ends up like this in the
>> final version, it should get a "@disable this();" to prevent misuse.
> It is for ment for phobos not druntime. Anyway structs would mean all
> templates and people will scream template bloat. And this would break
> the design, which I find to be a valid use of classes and
> polymorphisms.  The StdIOLogger can have its default constructor called IMO.

No no, I was talking about the JobManager, not the Logger classes. No 
templates involved.

>>
>>>>   - For me this logger is completely worthless without any debug log
>>>>     levels. The last std.log entry had at least anonymous verbosity
>>>>     levels, but I'd prefer something like I did in vibe.d [1], where
>>>>     each level has a defined role. This should especially improve the
>>>>     situation when multiple libraries are involved.
>>> Logger.log(LogLevel.(d|D)ebug, "Your message");
>> That would be my idea. Having at least two (diagnostic output for the
>> user and debug output for the developer), but better all four debug
>> levels can be very useful, though.
> Maybe I miscommunicated what I want to show by that example. The (d|D)
> part is the rename to enum lower case.
> The debug log level is given through the LogLevel.Debug, which will be
> renamed to LogLevel.debug. I would call the developer the user of the
> logger. Maybe log messages can be communicated to the user of the
> applicaiton and the developer of the application through a MultiLogger
> class.

But the statement of mine that you quoted was about debug levels (the 
case issue is clear)... Also right now there is no "(D|d)ebug" level, so 
I'm actually not sure about the statement that you want to make. But my 
example of having different levels for the application user and the 
developer is mostly important when the application user enables verbose 
log output to see where things go wrong. In that case things like system 
error codes and the like would make sense, but a repeated printout of 
some kind of internal buffer state would hardly help the user - it 
could, however, help the developer.

>> Thanks for bringing this forward!
>
> To whom is this directed?

To you for attempting to revive the logger topic.