Logger for D

sybrandy sybrandy at gmail.com
Sat Aug 28 05:45:04 PDT 2010


> Thanks. I think we should establish a tradition for reviews on this
> forum. The Boost review model has functioned very well, in the sense
> that it has consistently produced two outcomes: excellent libraries and
> pulp-beaten library authors. So I'd opt if at all possible for a tough
> review process that produces good libraries as opposed to a nicey-nicey
> process that fosters a low barrier of entry.

Understood and accepted.
> 
> As I guess you suspected already, I have a few critical comments about
> the proposed libraries. In brief, the library as proposed:
> 
> * does stuff that I don't care about (creation of logs, pluggable
> writers, overridable logging functions);

Examining each one individually:

1) creation of logs - Do you mean having to specify a log file?  I'm not
100% sure what you mean by this.

2) pluggable writers - Again, this was designed to be flexible as there
are different situations where different types of log writers are useful
and I didn't want to force one on the user.  I forgot to state this
before, my ideally I was hoping for several to be created and be part of
the logging library if it made it to Phobos.  This way several common
options could be provided by the standard library, but if for some
reason the user wanted something else, they could have it.

Part of the reason for doing this was to not have people coming up with
20 different logging libraries that behave differently and have
different interfaces just because the provided one doesn't work just the
way they want it to.  I felt it was a big step to allow the user to
change the writing process if needed to whatever suited their needs and
to keep how the logger was instantiated and used in code simple.

If you have a different vision, I'd like to hear about it.  Perhaps to
make things a bit simpler, but still retain the power, we could have a
default writer that will be used if no writer is specified.

3) overridable logging functions - If you don't mean the writer, then I
didn't mean to do that.
> 
> * does not do the two fundamental things that all loggers should do.
> 
> Those only two things are:
> 
> 1. Configure logging level during compilation
> 
> 2. Configure logging level during runtime

Actually, yes, it does do this.  If you change the log level in the
config file, it will be picked up by the logging library and the level
changed accordingly during execution.  I have a background thread that
checks the file very 10 seconds.  This way if you're running a server,
you can change the level as needed for debugging without stopping the
server.
> 
> If you want to have your library accepted in Phobos, I suggest you take
> a very close look at glog's interface and implementation. It's a simple
> and robust library used by two major companies that depend on good
> logging. To exaggerate a bit, "so"s seat-of-the pants sample code is
> closer to the ideal logging library than your current draft. But I am
> encouraged by the fact that you went through the aggravation to write
> the code and show it to everybody, so hopefully you'll have the
> willpower to push this through.

I will take a look at it and document the potential design first before
rewriting my code.

Casey


More information about the Digitalmars-d mailing list