Review of Jose Armando Garcia Sancio's std.log

[Steven Schveighoffer]

On Mon, 05 Mar 2012 20:22:05 -0500, so <so at 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 at 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. When you  
> see codes like this (below), you don't blame standard library designers  
> do you?
>
> using namespace std;
> int cout;

Except 'info', 'error', 'warning' are all common names, likely to be a  
very attractive name for something that has nothing to do with (or cares  
about) logging.  cout is not a common name or even an english word, so  
it's unlikely someone has or wants to create a cout member.

Couple this with the fact that all of these are nouns -- likely candidates  
for fields.

Your argument has some merit, but I would add that my argument is only  
against *common* global namespace names.

Another solution besides using a namespace is to make the names less  
common, like linfo instead of just info.

-Steve