Voting: std.logger

[Robert burner Schadek via Digitalmars-d]

On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:
> On Tuesday, 26 August 2014 at 21:04:28 UTC, Robert burner 
> Schadek wrote:
>
> ====================================
> Jakob Ovrum
> ====================================
>
> "The *API* must support minimal dynamic memory allocation for
> the normal execution path. However, theoretical *implementation*
> changes that reduce memory allocation are not a deal-breaker."
>
> This seems to be addressed but though it is desired to verify 
> it via @nogc unittest block which uses stub no-op logger (to 
> verify that nothing in between allocates). One place were GC 
> allocations is unavoidable is core.d:1628 - it will always 
> create FileLogger first and allow assigning custom one later. 
> Is there any way to circumvent it?
>
> "API must specify a strong stance on threading, whatever the
> form it takes"
>
> Does not seem to be addressed at all. At least I see no 
> mentions of it in core.d documentation and logger instance 
> itself is plain __gshared thing.
>
> $ grep -R -n "shared" std/experimental/logger/
> std/experimental/logger/core.d:1625:    static __gshared Logger 
> logger;
> std/experimental/logger/core.d:1635:    static __gshared 
> LogLevel ll = LogLevel.all;
>
> Does not seem enough for sure.

I working on this

>
> "This one might seem unnecessarily strict, but I think the fact
> that Logger is a class and not an interface smells of poor
> design. I might still be convinced that having it as a class is
> justified, but my current stance is that it must be an 
> interface."
>
> Neither does seem to be addressed nor I can find any comment on 
> why it is not going to be addressed.

Every Logger has to have a LogLevel, interfaces won't work there

>
> ====================================
> Francesco Cattoglio
> ====================================
>
> "As far as I undestood, there's no way right now to do logging
> without using the GC. And that means it is currently impossible
> to log inside destructor calls. That is a blocker in my book."
>
> First part partially addressed - missing @nogc @nothrow logger 
> implementation out of the box. Considering this request does 
> not go very well with current language implementation it may be 
> ignored for now but official stance about it must be clearly 
> documented.

at least for logf nothrow will not work because of a wrong 
formatting string or args. log can not be nothrow because custom 
toString for structs and class are allowed.

nogc is not possible because of custom toString

that won't fix, but for default types it is nogc.
>
> ====================================
> Byron Heads
> ====================================
>
>
> "Logger should include a shared Logger, or include it in the 
> interface for
> outside libraries to handle the implementation.  There will be 
> libraries
> that thread internally and will need to support shared logging."
>
> Is not addressed.

See Jakob Ovrun