Voting: std.logger

[Dicebot via Digitalmars-d]

On Tuesday, 26 August 2014 at 21:04:28 UTC, Robert burner Schadek 
wrote:
> On Tuesday, 26 August 2014 at 18:23:31 UTC, Dicebot wrote:
>>
>> I will compare changelist against list of requirements from 
>> voters this weekend and if all seems to be addressed will 
>> start a new round of review/voting.
>
> sounds good!
> just to note, I will be mostly offline for a good week starting 
> friday.

Ok, going through the list of "No" voters.

====================================
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.

"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.

====================================
Andrei Alexandrescu
====================================

"Minimal logging level must be selected statically in addition to 
the
current dynamic selection. Static settings preclude dynamic 
settings.
This is not negotiable."

Seems to be addressed.

"All logging code must be rigorously eliminated if below the 
static
logging level. More precisely, there must be a front-end 
optimization
that eliminates all code dedicated to a "lazy" variable that's 
not used
by a generic function. This would be a fantastic redeeming of the 
"lazy"
keyword, which has been of marginal utility until now. The 
challenge
here is cooperating with someone on the compiler team to make 
sure that
front-end improvement gets implemented, and writing unit tests 
that make
sure there's no regression later. This is not negotiable."

Seems to be addressed.

"The suffix notations must be replaced with overloads. The only
acceptable suffix is "f" for formatting. Everything else must be
achieved via overloads with the help of template constraints. 
Robert's
answer http://goo.gl/FehDVh suggests he didn't consider using 
template
constraints. We can't let that slip become a feature of the 
library for
millenia to come."

Seems to be addressed.

"Replace defaultLogger with theLog. "Logger" is a word, but one 
that
means "lumberjack" so it doesn't have the appropriate semantics. 
The use
is generally acceptable as a nice play on words and as a 
disambiguator
between the verb "to log" and the noun "log". When we actually 
want to
talk about the current log in an application, we should, however, 
call
it "the log". This is negotiable."

Addressed with a name of "stdlog".

"I'm still hoping for RefCounted as the storage for the class 
backend.
I realize users can do their own management but log objects are 
unlikely
to contain cycles and other liabilities for reference counting, 
and at
some point if we want to use reference counting where appropriate 
we got
to start somewhere with a few solid precedents. This is 
negotiable, but
I plan to fight for it."

Can't see any traces of RefCounted in sources though I may have 
missed change of mind in PR discussion (sorry it is too huge to 
pay regular attention)

====================================
Casey
====================================

"However, I wanted to address the suffix notation as
I suggested it.  What I was going for was consistency with the
write/writef method signatures to keep things consistent.  I felt
it would be good to make the two similar since they do similar
things."

Obsolete with overload-based resolution

====================================
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.

====================================
Byron Heads
====================================

"We need to hammer out how this will work inside libraries.  If 
my app is
using multiple libraries I need to know I have full control of 
how they
log and where (), and if I write libraries I need to include 
logging that
will not affect performance or added dependencies.

I like the idea of a standard interface for D logging.  Other 
logging
implementations should be able to plug into the interface without 
having
to inherit from std.log.Logger (single inheritance issue).

I would like to see conditional logging as part of the interface, 
or in
the documentation show how we can achieve that with stdlib in a 
clean and
simple way."

Addressed.

"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.