Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques <sandford at jhu.edu> wrote:
> On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia <jsancio at gmail.com>
> wrote:
>
>> On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dlang at mesadu.net>
>> wrote:
>>>
>>> When logging the severity level should convey a certain insight that the
>>> developer has about the code. This can be done with a 3 bit field. These
>>> are: known-cause, known-effect and breaks-flow.
>>>
>>> This creates the following matrix:
>>>
>>> KC KE BF Severity
>>> =================
>>> 1  1  0  Trace
>>> 0  1  0  Info
>>> 1  0  0  Notice
>>> 0  0  0  Warning
>>> 1  1  1  Error
>>> 0  1  1  Critical
>>> 1  0  1  Severe
>>> 0  0  1  Fatal
>>>
>>> A known cause is when the developer knows why a log event is made. e.g.:
>>> if
>>> you cannot open a file, you do not know why.
>>> A known effect is when he/she knows what happens after. Basically, you
>>> can
>>> tell if it is a catch-all by this flag.
>>>
>>> When a severity should only be handled by a debugger, the normal debug
>>> statement should be used. This is in essence a 4th bit.
>>>
>>> I hope this helpful in the search for a good level system.
>>>
>>
>> Interesting observation on logging. I like your theoretical
>> observation and explanation. To me the most important thing is
>> usability and unfortunately people are used to log levels as a order
>> concept. Meaning error is higher severity than info so if I am logging
>> info events I should probably also log error events.
>>
>> If we go with a mechanism like the one you describe above there is no
>> order so the configuration is a little more complicated or verbose I
>> should say. Instead of saying we should log everything "greater" than
>> warning the user needs to say that they want to log known-cause,
>> known-effect, breaks-flow events. This mean that there are 27 (= 3^3)
>> configuration combinations. To implement this we need 3 configuration
>> nobs with 3 values (on, off, both).
>>
>> Thoughts?
>> -Jose
>
>
> There are only 8 possible configurations and they are nicely ordered in
> terms of severity. So I don't see this as a problem. Also, if you went with
> a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27 values?

Yes. If you want to enable and disable each individual "level" then
you need 8 configuration options which leads to 2^8.

I suggested 3^3 as a more reasonable options that matches how the
developer is logging but doesn't give you as much expressiveness as
the 2^8 option.