Early review of std.logger

Sönke Ludwig sludwig at outerproduct.org
Mon Oct 14 05:39:59 PDT 2013


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.digitalmars-d@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


More information about the Digitalmars-d mailing list