I've added the standardized APIs for logging. It is similar to log4j but much simpler. I tried to keep the class numbers to an absolute minimum since this is a sys API, but in the end I needed three new classes: Log, LogLevel, and LogRecord.
I played around with a couple designs, and in the end settled on the key principle that Logs have to be const, immutable so they can be easily shared between threads. The result of that approach is that CompilerLog couldn't subclass from Log since it is stateful. That seems ok b/c CompilerLog isn't really a "broadcast" kind of log, but rather just a mechanism to accumulate compiler errors. I tried a design where sys::Logs could be named (immutable and shared) and anonymous (mutable and thread local), but in the end it seemed ugly. So I settled for making CompilerLog duck typed like Log with the same signatures.
Logging is documented in detail in docLang::Logging with quick examples in docCookbook::Logging.
brian Sun 23 Dec 2007
I've added the standardized APIs for logging. It is similar to log4j but much simpler. I tried to keep the class numbers to an absolute minimum since this is a sys API, but in the end I needed three new classes: Log, LogLevel, and LogRecord.
I played around with a couple designs, and in the end settled on the key principle that Logs have to be const, immutable so they can be easily shared between threads. The result of that approach is that CompilerLog couldn't subclass from Log since it is stateful. That seems ok b/c CompilerLog isn't really a "broadcast" kind of log, but rather just a mechanism to accumulate compiler errors. I tried a design where sys::Logs could be named (immutable and shared) and anonymous (mutable and thread local), but in the end it seemed ugly. So I settled for making CompilerLog duck typed like Log with the same signatures.
Logging is documented in detail in docLang::Logging with quick examples in docCookbook::Logging.