On Tuesday, 6 March 2012 at 01:33:05 UTC, Jonathan M Davis wrote:

> And I really don't think that this merits it.
> log!info(msg) would work just fine and would be _far_ better.

Now you got not only "info" but "log" in global namespace :)
I think you meant "log.info".

On Mon, 05 Mar 2012 19:22:05 -0600, so <so@so.so> wrote:
> On Monday, 5 March 2012 at 23:51:29 UTC, Steven Schveighoffer
> wrote:
>> On Mon, 05 Mar 2012 18:30:03 -0500, David Nadlinger
>> <see@klickverbot.at> wrote:
>>
>>> On Monday, 5 March 2012 at 21:55:08 UTC, Steven Schveighoffer
>>> wrote:
>>>> The log aliases use names that are too common.  I think
>>>> log.info is a better symbol for logging than just 'info',
>>>> which could be a symbol in a myriad of places.  Given that
>>>> D's symbol lookup rules allow shadowing of global symbols,
>>>> this does not work out very well.
>>>
>>> Originally, the code used log!info and so on, but it was
>>> changed to the current design right after review begin, the
>>> rationale being that you could always use »import log =
>>> std.log« if you want the extra namespace.
>>
>> That doesn't help.  Software isn't static.
>>
>> import std.log;
>> import other; // defines B
>>
>> class A : B
>> {
>>    void foo()
>>    {
>>       info("some info message"); // error! int isn't a function!
>>    }
>> }
>>
>> other.d:
>>
>> class B
>> {
>>    int info; // added later
>> }
>
> That is not a counter-argument to something related to this
> library but everything that lies in global namespace.
> At its first state both severity levels and the "log" was in
> global namespace. Now only severity levels.
>
> You are also overlooking one crucial fact that this library will
> be part of phobos, standard library. Which requires everyone to
> adopt.

Please don't forget that you are _submitting_ a library into Phobos and the D ecosystem at large. Yes, new code can be expected to avoid these names, but all existing code has to be retrofitted and fixed.

On 2012-03-06 02:32, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 02:22:05 so wrote:
>> That is not a counter-argument to something related to this
>> library but everything that lies in global namespace.
>> At its first state both severity levels and the "log" was in
>> global namespace. Now only severity levels.
>>
>> You are also overlooking one crucial fact that this library will
>> be part of phobos, standard library. Which requires everyone to
>> adopt. When you see codes like this (below), you don't blame
>> standard library designers do you?
>>
>> using namespace std;
>> int cout;
>
> Except that cout is not exactly something that would be considered a normal
> variable name. Something like info _is_. This logging module is taking
> incredibly common names and shoving them as far into the global namespace as
> anything can go in D which isn't a compiler built-in. _Not_ a good idea IMHO -
> not without good reason. And I really don't think that this merits it.
> log!info(msg) would work just fine and would be _far_ better.
>
> - Jonathan M Davis

The user can then alias "log!info" to "info" if he/she wants to.

-- 
/Jacob Carlborg

On Tuesday, March 06, 2012 08:46:14 Jacob Carlborg wrote:
> On 2012-03-06 02:32, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 02:22:05 so wrote:
> >> That is not a counter-argument to something related to this
> >> library but everything that lies in global namespace.
> >> At its first state both severity levels and the "log" was in
> >> global namespace. Now only severity levels.
> >> 
> >> You are also overlooking one crucial fact that this library will be part of phobos, standard library. Which requires everyone to adopt. When you see codes like this (below), you don't blame standard library designers do you?
> >> 
> >> using namespace std;
> >> int cout;
> > 
> > Except that cout is not exactly something that would be considered a
> > normal
> > variable name. Something like info _is_. This logging module is taking
> > incredibly common names and shoving them as far into the global namespace
> > as anything can go in D which isn't a compiler built-in. _Not_ a good
> > idea IMHO - not without good reason. And I really don't think that this
> > merits it. log!info(msg) would work just fine and would be _far_ better.
> > 
> > - Jonathan M Davis
> 
> The user can then alias "log!info" to "info" if he/she wants to.

The user can do whatever aliases they want. It's just that we shouldn't unnecessarily use really common names at the top level, since then they'll conflict with a lot of stuff.

- Jonathan M Davis

On Tuesday, 6 March 2012 at 07:46:14 UTC, Jacob Carlborg wrote:
> On 2012-03-06 02:32, Jonathan M Davis wrote:

> The user can then alias "log!info" to "info" if he/she wants to.

Again, you are now forcing 2 common names instead of one as it is now.
When you instantiate log!info where do you get "info" from?

On 2012-03-06 08:54, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 08:46:14 Jacob Carlborg wrote:
>> On 2012-03-06 02:32, Jonathan M Davis wrote:
>>> On Tuesday, March 06, 2012 02:22:05 so wrote:
>>>> That is not a counter-argument to something related to this
>>>> library but everything that lies in global namespace.
>>>> At its first state both severity levels and the "log" was in
>>>> global namespace. Now only severity levels.
>>>>
>>>> You are also overlooking one crucial fact that this library will
>>>> be part of phobos, standard library. Which requires everyone to
>>>> adopt. When you see codes like this (below), you don't blame
>>>> standard library designers do you?
>>>>
>>>> using namespace std;
>>>> int cout;
>>>
>>> Except that cout is not exactly something that would be considered a
>>> normal
>>> variable name. Something like info _is_. This logging module is taking
>>> incredibly common names and shoving them as far into the global namespace
>>> as anything can go in D which isn't a compiler built-in. _Not_ a good
>>> idea IMHO - not without good reason. And I really don't think that this
>>> merits it. log!info(msg) would work just fine and would be _far_ better.
>>>
>>> - Jonathan M Davis
>>
>> The user can then alias "log!info" to "info" if he/she wants to.
>
> The user can do whatever aliases they want. It's just that we shouldn't
> unnecessarily use really common names at the top level, since then they'll
> conflict with a lot of stuff.
>
> - Jonathan M Davis

What I'm trying so say is that if we use the template function the user can get the best of both worlds.

-- 
/Jacob Carlborg

On Tuesday, 6 March 2012 at 03:11:11 UTC, Robert Jacques wrote:

> Please don't forget that you are _submitting_ a library into Phobos and the D ecosystem at large. Yes, new code can be expected to avoid these names, but all existing code has to be retrofitted and fixed.

Probably it is the reason why they use cryptic variable names in C++ std library :)

On Tuesday, March 06, 2012 09:14:16 so wrote:
> On Tuesday, 6 March 2012 at 07:46:14 UTC, Jacob Carlborg wrote:
> > On 2012-03-06 02:32, Jonathan M Davis wrote:
> > 
> > The user can then alias "log!info" to "info" if he/she wants to.
> 
> Again, you are now forcing 2 common names instead of one as it is
> now.
> When you instantiate log!info where do you get "info" from?

Yes. My mistake - probably because the time stuff typicall takes such a template argument as string, which would make this log!"info"(msg). However, adding _log_ isn't necessarily bad, given that this is std.log that we're talking about. It's info and the rest that are the problem.

- Jonathan M Davis

On Mon, Feb 27, 2012 at 10:10 AM, Kalle Svensson <kalle@ieee.org> wrote:
> Since I'm D n00b I'll just post a couple of observations:
>
> * I agree that it is a good idea just to use few log levels.
>
> * I think is it is a misstake not to let formatting of the whole log message be pluggable (i.e. not the free text message the programmer writes). If I have created a special RFC5424 formatter (with MSGID and STRUCTURED-DATA fields set according to the will of my corporate masters) I want to resuse it in both the FileLogger and a future TcpLogger without having to use inheritance. Your "line format" formatter in FileLogger is a good default formatter though.
>

I agree but I am some what hesitant to add this now as it will just prolongs everything. I think we can add this in the future without breaking compatibility with code that was written against it.

>    ///Kalle
>

On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dlang@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