OT: std.logger was Re: std.experimental Timeline

[Jonathan M Davis via Digitalmars-d]

On Monday, 4 January 2016 at 13:48:16 UTC, Robert burner Schadek 
wrote:
> On Monday, 4 January 2016 at 10:58:09 UTC, Jonathan M Davis 
> wrote:
>> So, to work for them, they would need std.experimental.logger 
>> to accept something like const(char)[] or an arbitrary ranges 
>> of characters and to not allocate inside of any of its logging 
>> functions. Any requirement to convert to string (be it by the 
>> user of the logger or inside of the logger itself) doesn't 
>> work with their requirements.
>
> as said above, no Logger has to allocate for logging, and no 
> string has to be created.
>
> An allocation schema was selected however, to make multi 
> threading work by default.
> Creating a user specific Logger that fits the Logger interface 
> and that uses a static buffer to write the data to is properly 
> less than 20 lines of code.

Well, looking at your implementation in your other post, you're 
able to make it work by casting to string when it's not actually 
a string. So, you're circumventing the type system to make it 
work. Depending on what the base class does with the resulting 
string, it may work, but there's no guarantee that it will, 
especially if you end up deriving your logger class from a 3rd 
party one. For this code to be safe, msg in LogEntry really needs 
to be const(char)[] and not string.

>> I'm not particularly familiar with std.experimental.logger as 
>> it stands, by I would guess that to fit Sociomantic's 
>> requirements, it would need to either manage to log without 
>> actually constructing any array of characters (e.g. by 
>> printing each of its elements in turn without actually putting 
>> them together first), or it would need to reuse a buffer every 
>> time it created the line to log (which would incur the cost of 
>> copying the characters but wouldn't normally have to 
>> allocate). But I don't know how well that fits in with the 
>> logger being hierarchical via classes (which solves other 
>> design requirements) or how close the current implementation 
>> is to that. Certainly, being forced to use classes does 
>> prevent the logger from using some of the typical techniques 
>> that we use (particularly with regards to ranges). So, the 
>> logger definitely presents some challenges that most other 
>> Phobos code doesn't have to deal with. :| Though obviously, 
>> you'd be more aware of that than anyone. :)
>>
>> - Jonathan M Davis
>
> If you guess of their requirements is correct, 
> std.experimental.logger fulfills the requirements.

Only by doing a risky cast that happens to work in a reduced 
example but does not work in the general case. Now, the changes 
required to avoid the cast should be minimal and straightforward, 
but as long as a cast to string is required in order to avoid 
allocating a string, the logger doesn't safely support avoiding 
allocations.

My guess is that it didn't even occur to Dicebot to make the 
cast, but I doubt that he would be happy with that solution 
anyway, particularly given the recent PR and related discussion 
on adding message to Throwable (which returns const(char)[]): 
https://github.com/D-Programming-Language/druntime/pull/1445

Regardless, Dicebot will obviously have to talk with you about 
their requirements and why he thinks that std.logger doesn't fit 
them.

- Jonathan M Davis