Review: std.logger

[ponce via Digitalmars-d]

On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:
>>
>> I'm in 100% disagreement. If you don't add the f suffix, users 
>> will write:
>>
>> info(<user provided string that could contain format>);
>>
>> This is a crash if the user provided string happens to 
>> contains "%s".
>> I wouldn't use such an API which makes format bugs hard to 
>> find.
>>
>
> It does the right thing... there is an overload: without 
> additional arguments, the first argument (not necessary a 
> string) is not a format string.
>

Now if write a bug:
warning("there was an error because the file %s is missing!");

and I forgot the argument, no problem, it will run without 
errrors despite I made one. This is not an improvement over 
writef.

(this particular bug came up in DUB among others, and my last 
example was a real case too in production software where the 
users would call things with "%" in the names)

Two different operations conceptually => two names.

>>
>>
>>> 2. No support for 24/7 (server) applications
>>>
>>> In my opinion, I really need logging for applications that 
>>> possibly run forever.
>>> With the FileLogger, the file will grow forever.
>>> That's why most other frameworks provide something like a 
>>> RollingFileLogger or some "logrotate-aware" FileLogger.
>>
>> Do you realize rolling loggers are not there because they are 
>> supposed to be in another layer as subclasses of Logger?
>>
>
> Contrary to the NullLogger, writing a rolling logger is a 
> non-trivial task.

NullLogger is there precisely because it's trivial and needed.
Of course a rolling logger is not that trivial, but std.logger is 
there to be orthogonal and a foundation not providing everything 
non-trivial.