Voting: std.logger

[Andrei Alexandrescu via Digitalmars-d]

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/zhvmkbahrqtgkptdlcvh@forum.dlang.org
>
> 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