Am 14.10.2013 13:39, schrieb Dicebot:
As `std.logger` is still marked as "work in progress" this thread is
less formal that typical pre-voting review. Goal is to provide as much
input about desirable `std.logger` functionality and current state and
let module author to use this information for preparing proposal for
actual review / voting.
Lets unleash the forces of constructive destruction.
===== Meta =====
Code: https://github.com/D-Programming-Language/phobos/pull/1500/files
Docs: http://burner.github.io/phobos/phobos-prerelease/std_logger.html
First announcement / discussion thread :
http://forum.dlang.org/post/mailman.313.1377180809.1719.digitalmar...@puremagic.com
Sorry in advance for the long list of issues. I think the general
approach is fine, but over the years I've grown some preferences for
this stuff. Generally, I think we should make sure that such a module is
flexible enough to fulfill most people's needs, or it will probably fail
the widespread adoption that is desired to actually improve
interoperability.
- LogLevel: enum values should start lower case according to the
Phobos conventions.
- The static methods in LogManager should be made global and the class
be removed. It's not for objects so it shouldn't be a class.
- For me this logger is completely worthless without any debug log
levels. The last std.log entry had at least anonymous verbosity
levels, but I'd prefer something like I did in vibe.d [1], where
each level has a defined role. This should especially improve the
situation when multiple libraries are involved.
- My experience tells me that logging formatted messages by default
(or even drop the non-formatted version) is perfectly fine, but
others may differ of course and an additional "f" is not that bad.
- Similarly, I've never felt the need for conditional logging, but
without it being lazy evaluated what's the use for it, actually?
- I really think there should be shortcuts for the different log
levels. Typing out "LogLevel.xxx" each time looks tedious for
something that is used in so many places.
- There should be some kind of MultiLogger so that multiple log
destinations can be configured (e.g. console + file). Or, instead of
a single default logger, there could be a list of loggers.
- Logger.logMessage: Exchanging the bunch of parameters with a single
struct that is passed by reference makes the API much more
flexible/future-proof and is more efficient when the data needs to
be passed on to other functions.
- "shared" - probably best to leave this out until we have a verified
design for that - but in theory the loggers should probably be
shared.
- On the same topic, if I'm right and the default logger is stored as
__gshared, it should be documented that Loggers need to be
thread-safe.
- GC allocations for each log message _must_ be avoided at all costs.
Using formattedWrite() instead of format() on either a temporary
buffer that is reused, or, better, on some kind of output range
interface of the Logger would solve this.
- A note on DDOC comments: The first paragraph of a doc comment is
treated as a short description according to the DDOC spec. It should
be kept to around a single sentence, followed by a more detailed
paragraph. While this doesn't matter much with the current HTML doc
layout, the short description is used in the single-page
documentation inside of overview tables [2].
[1]: http://vibed.org/api/vibe.core.log/LogLevel
[2]: http://vibed.org/temp/d-programming-language.org/phobos/std/ascii.html
