Early review of std.logger

[Robert Schadek]

On 10/14/2013 08:55 PM, Sean Kelly wrote:
> It's weird that LogManager.defaultLogger exists as a read-only
> property, and if I want to change it I have to use the global static
> "log" variable.
this will be properly be fixed in the next incarnation (tonight, no
promises)
>
> I think this was mentioned elsewhere, but is the global logger
> thread-local, shared, or __gshared?  Or is this something we can
> control?  I can see maybe wanting to have a separate logger per thread
> in some cases, for example.
>
currently all are thread local. the default logger will properly be
gshared. the others, I wish I could predict the shared discussion outcome.
> I kind of wanted channels per Boost::Log, but simply creating multiple
> loggers that I can reference by name seems reasonable.  Channels add a
> ton of complexity anyway.
>
> We really need timestamps, and the timestamp format should be
> configurable.  One thing I like about Boost::Log is that I can
> statically specify the format of log lines.  This would be
> particularly useful when trying to integrate a D app into a setup that
> already expects a particular log line format.
timestamps will be in
>
> This is an implementation detail, but I imagine the buffer these lines
> are written into is a static buffer that grows as needed and is just
> reused for each log line written?  I understand why a custom logger
> would receive only the generated log string, but if this is allocating
> unnecessarily in the background it could be a problem.  Maybe we could
> get some way to specify the initial size of this internal buffer as
> well, or limit the total buffer size to some value?  In some cases,
> you don't want to log more than N bytes per entry even if it means
> truncating the message.
>
> Formatted logging should be the default.  I almost never want to just
> long a string with no parameters.
>
> I'm not entirely happy with the conditional just sitting in the
> parameter list.  Maybe if the command were "logIf" instead of just
> "log" or there were some way to mark up the conditional in code as
> that it determines whether the log line is written...  I think this
> goes with my general aversion to using magic numbers as function
> parameters.  I either like the function call to read line a sentence
> or if that isn't reasonable, for there to be some way to indicate what
> a particular parameter is for.
I'm not sure what is the best, all fitting way here.
>
> For what it's worth, I think the conditional is a reasonable
> substitute for not having the LogLevel be a bitmask.
>
> For the rest, I think the current API is sufficient to make most use
> cases work.  I might sometimes create a proxy logger than fans out to
> multiple discrete loggers underneath, for example.  But that seems
> straightforward.