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.
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.
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.
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.
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.
