On 7/28/14, 10:11 PM, Dicebot wrote:
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period which will
last two weeks starting from now.
Discussion thread :
http://forum.dlang.org/post/[email protected]
This voting will be somewhat different from previous ones because it
will be done with std.experimental in mind. Because of that please reply
with a bit more structured votes:
My vote is a qualified "yes" contingent upon fixes that I'll give detail
on below. In the current form my vote is "no" seeing as the module makes
a number of unforced tactical errors. Overall I think the goods are
there, and are easy to put in acceptable form.
1) Yes / No for inclusion into std.experimental
At this point please consider if module has functionality you want to
see in standard library in general and if implementation is not
fundamentally broken. This is a simple sanity check.
No in current form. Yes assuming the fixes below are implemented.
2) Yes / No for inclusion into Phobos in its current state
This is where you should summarize your concerns raised during review if
there are any and make decision if existing API / architecture are
promising enough to be set in stone via Phobos inclusion.
No. I also think any new module should sit in std.experimental for one
release cycle.
3) If you have answered "No" for (2) : list of mandatory changes that
are needed to make you vote "Yes"
Here's my list:
1. Minimal logging level must be selected statically in addition to the
current dynamic selection. Static settings preclude dynamic settings.
This is not negotiable.
2. 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.
3. 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.
The overloads must be:
// just log stuff
log(T...)(lazy T stuff) if (!is(T[0] : const LogLevel));
// log with format
logf(S, T...)(lazy S fmt, lazy T stuff) if (isSomeString!Str);
// log conditional with format
logf(S, T...)(lazy bool cond, lazy S fmt, lazy T stuff) if
(isSomeString!Str);
These three overloads should be repeated for all logging functions
(info, trace etc). The functions don't evaluate their arguments if the
respective log level is disabled.
The following functions will NOT be repeated for all logging functions:
// just log stuff at some level
log(T...)(LogLevel lvl, lazy T stuff) if (!is(T[0] : const LogLevel));
// log with format
logf(S, T...)(LogLevel lvl, lazy S fmt, lazy T stuff) if (isSomeString!Str);
// log conditional with format
logf(S, T...)(LogLevel lvl, lazy bool cond, lazy S fmt, lazy T stuff) if
(isSomeString!Str);
These overloads always evaluate their first argument eagerly to
determine the required logging level. Depending on it they may or may
not evaluate their other arguments.
This is not negotiable.
4. 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.
5. I was hoping for a resolution on throttling. However, now I realize
that conditional logging plus throttling functions that return true once
in a while should work acceptably well. Higher-order functions taking
lambdas that log would also be a nice possibility. So... no request here.
6. 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.
4) Any additional comments for author.
Don't let any of the above discourage you. This is great work and is
already one foot in. Let's get this done and done. Don't forget - it's
all about Deutsche Gründlichkeit!
Andrei
