I was considering making some improvements to the logging package to
provide some more advanced logging functionality (ultimately, this was
inspired by the google-glog C++ logging library at http://code.google.com/p/google-glog/).
More specifically, I would like to be able to differentiate my log
message as being one of {INFO, WARNING, ERROR, FATAL} and have a
threshold for determining which log messages appear. In addition, I
want to support the ability to provide user specified verbosity levels
with something equivalent to VLOG(n). The google-glog library supports
several other nice things, including LOG_IF, LOG_EVERY_N, LOG_FIRST_N,
and CHECK macros as well as support for logging to files, etc.
I started tinkering with some code to see what kind of effort this
would require. In trying to keep the log message short and of a
similar form to the LOG(INFO) << "message" used in the C++ package,
I've been using a design where log statements would take the form:
log.INFO().Outf("Invalid port: %d", port)
In this example, the INFO() function returns an interface with two
functions: Out and Outf. By making INFO() a function, I allow it to
return a dummy object (for which Out and Outf are both noops) in the
case where no log message would appear. The arguments themselves are
still evaluated, but I figured that this was still a reasonable trade
off (and I do not believe it is any different in the C++ library).
WARNING() and ERROR() behave in similar ways, and FATAL() additionally
terminates the program. This pattern also works for user specified
verbosity levels:
log.VLOG(3).Out(foo)
It seems that there is a relatively common misconception that C/C++
logging packages skip argument evaluation when the log message isn't
logged (for now, I'll just refer to the google-glog package although I
acknowledge others may behave differently). This simply cannot be
true. In order for this to occur, one would have to know at compile
time what level of logging granularity is desired - in order to set
the granularity at run time, the messages would have to be logged.
I am willing to spend some effort improving the currently logging
package by add levels for semantic content and some support for
filtering by this content (in a manner similar to the google-glog
package). While I would attempt to reduce the overhead when messages
aren't logged, my goal would primarily be to offer more useful logging
to users of the package. Likewise, LOG_IF and LOG_EVERY_N type macros
would be used to filter log messages.
Please correct me if I am misunderstanding you, but are you suggesting
that Go will not consider improvements to the existing logging package
because they would lack the ability to omit LOG() statements from
release binaries? Isn't this a feature the existing package lacks?
That said, I'm skeptical that the kind of thing you're after belongs
in the standard logging package.
-rob