On Friday, 1 August 2014 at 17:06:24 UTC, Daniel Murphy wrote:
> "Dicebot"  wrote in message news:pnwgrcqfuhkzcaasatti@forum.dlang.org...
>
>> I am afraid we don't have the right way in D then. Caring about cross-module name conflicts feels too much like plain C.
>
> But with overloading!
>
> It isn't just about avoiding conflicts - if the function name is unique, you can tell what the code is doing without having to examine the context so closely.  This is especially important for the standard library, because the time spent learning names can be reclaimed over multiple projects.

If you find this important, you can always require renamed / static imports in your projects. On the contrary, if function name is already qualified with some redundant information, there is no simple way back other than aliasing all symbols from that module.

I am convinced we are missing good style of using D import system, not good names.

> This is a strength of C, although C goes way too far with forcing it.

There are surprisingly many things I miss from C but manual name mangling is not in that list.

On 8/1/14, 6:08 PM, Dicebot wrote:
> On Friday, 1 August 2014 at 17:06:24 UTC, Daniel Murphy wrote:
>> "Dicebot"  wrote in message news:pnwgrcqfuhkzcaasatti@forum.dlang.org...
>>
>>> I am afraid we don't have the right way in D then. Caring about
>>> cross-module name conflicts feels too much like plain C.
>>
>> But with overloading!
>>
>> It isn't just about avoiding conflicts - if the function name is
>> unique, you can tell what the code is doing without having to examine
>> the context so closely.  This is especially important for the standard
>> library, because the time spent learning names can be reclaimed over
>> multiple projects.
>
> If you find this important, you can always require renamed / static
> imports in your projects. On the contrary, if function name is already
> qualified with some redundant information, there is no simple way back
> other than aliasing all symbols from that module.
>
> I am convinced we are missing good style of using D import system, not
> good names.

To an extent I agree, but I have to side with the view that common artifacts in stdlib can cause quite some annoyance. I remember bug reports being made about clashing symbols between (I forgot exactly) std.string, std.regex, and std.algorithm. Clearly avoiding those clashes was all business as usual, but that doesn't mean we can't make things a tad better for standard library users.

Andrei

On 08/02/2014 03:19 AM, Andrei Alexandrescu wrote:
> Clearly avoiding those clashes was all business as usual,

The newly introduced _private_ aliases would have possibly led to more clashes, aggravating the issue.

"Dicebot"  wrote in message news:aulaiptmiywxykqyhppt@forum.dlang.org...

> There are surprisingly many things I miss from C but manual name mangling is not in that list.

I don't like manual name mangling, but I like being able to look at a line of code and know exactly what it does.  There are other factors, but this is an important one.

I know using IDEs makes the cost of finding out what it actually does much lower, but it's a cost nonetheless. 

On Friday, 1 August 2014 at 20:20:00 UTC, Jeremy Powers via Digitalmars-d wrote:
>>
>> Can you tell, what `log(1)` does?
>>
>
> Is there a irrefutable requirement to have a log function without explicit
> level?

As I understand, it's a defensive feature. There are things one wants in the log unconditionally, like OS version and program version. They can be logged at fatal level, but that's a workaround and looks confusing, and still can be filtered.

>
> Is there a[n] irrefutable requirement to have a log function without
>> explicit
>> level?
>>
>
> As I understand, it's a defensive feature. There are things one wants in the log unconditionally, like OS version and program version. They can be logged at fatal level, but that's a workaround and looks confusing, and still can be filtered.
>

Believe that's what the 'off' level is for, though it is confusingly named (off as in no filtering, not no logging).  Maybe better called 'always'?


I contend that having bare log methods without a specified level is a mis-feature.  They may be useful as a shortcut when the desired level is unknown/irrelevant, but I don't believe what they add is worth the bother.

>
> As I understand, it's a defensive feature. There are things one wants in
>> the log unconditionally, like OS version and program version. They can be logged at fatal level, but that's a workaround and looks confusing, and still can be filtered.
>>
>
> Believe that's what the 'off' level is for, though it is confusingly named (off as in no filtering, not no logging).  Maybe better called 'always'?
>

Looking at the current version of the logger code, there is nothing that will always be logged - if the logging level (global or logger) is set to 'off' it will not log even if you call log() without a level.  So a bit of clarifying around this may be desired.



>
> I contend that having bare log methods without a specified level is a mis-feature.  They may be useful as a shortcut when the desired level is unknown/irrelevant, but I don't believe what they add is worth the bother.
>

Leaving this quote in, since it's my main point - I think not having a bare log() method is better than having one.  Log levels are pretty basic to the idea of logging (as done here and most everywhere else), trying to ignore them just moves the complexity elsewhere.

'always' or 'unfiltered'
I'm fine with logl(LogLevel.max,...); I expect it to be used rarely. Well, maybe not logging anything when the level is set to 'off' makes sense, it just should work on any other level.

On Friday, 1 August 2014 at 15:52:30 UTC, Martin Nowak wrote:
> Well phobos as a library is precompiled, so the versions used to compile phobos will be relevant, not the ones in client code.
>
> For templated functions version identifier will "leak" from client code into the library, because technically they are instantiated by the client code.

could you elaborate please? Currently I use the version statements in two template functions. I'm not sure why one would brand this negatively as a leak into the library.

>
> Also the version identifiers of client code determine which declarations you see.
>
> Relying on this would be a constant source of bugs.

could you elaborate please?

>
> I did proof-of-concept yesterday using type tags and template constraints to statically disable certain log levels.
> It also has some drawbacks because LogLevel is no longer a plain enum, but it's more appropriate than version identifiers.
> http://forum.dlang.org/post/lrf362$tkn$1@digitalmars.com

Thank you for taking the time, but I found several conceptional problems with that POC. The worst being that if I make the LogLevel inside the TestLogger anything other than a enum it fails, as it is used in the template constraint. That would mean the LogLevel is fixed at CT.

Voting ends tomorrow, summary post may get delayed for a few days though.