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.
