Early review of std.logger

[Robert Schadek]

On 10/15/2013 02:44 AM, Kapps wrote:
> A few concerns:
>
> There doesn't seem to be a debug or trace log level. This is quite a
> useful thing to have once your program is deployed.
there is a LogLevel.debug and a LogLevel.info
>
> I don't like the returning by ref for log methods. For example, it
> seems like you can do: log(5 < 4, "This is a test log") = new
> StdIOLogger();
> It could potentially be useful to return the Logger so you can chain
> calls and such, but it should not be possible to set the logger by
> assigning the result of a log call.
I saw this, but this comes from the way you get the default logger. I
don't think that this is that bad, but I bet somebody will disagree.
>
> The simple act of logging a message is very verbose right now:
> log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
> prefer something like log.trace("Creating new pool") and log("Creating
> new pool") where the latter would use opCall to forward to the default
> log level. If it's intentional that you can assign the result of log,
> this also helps that because log = new StdIOLogger would be possible
> (log being a property that returns a Logger, and so a setter could be
> made), but log("Creating new pool") = new StdIOLogger() would not be.
The LogLevel is optional. And always writing log.trace might become more
typing work and assigning a LogLevel and than calling log("..."). Both
have pros and cons
>
>
> There's a lot of suggestions for things like network logging, but I
> think this is far beyond the scope of the module, and the sheer amount
> of different ways of doing it means people will likely write their own
> anyways. For example, synchronous vs asynchronous, what protocol to
> use, authentication, client data, encryption, etc.
my point exactly