Naming conventions for functions in similar modules

[so]

On Wed, 22 Jun 2011 09:17:56 +0300, Andrej Mitrovic  
<andrej.mitrovich at gmail.com> wrote:

> Another example is std.parallelism.taskPool. It's nice to see code like  
> this:
> taskPool.reduce!"a + b * b"(0.0, nums);
>
> I'll never mistake that for std.algorithm.reduce. And it's not too hard  
> to type.

I am confused, you said typing module names tedious and now you are saying  
it is fine typing taskPool.reduce every time.
If adding "taskPool" at the beginning is not a problem then so is adding  
"algorithm". How about this improvement?
If we are able to refer std.module.foo as foo, why can't we refer it as  
module.foo? The reason probably is the confusion arises when  
"fun.mod.impl" and "mod.impl" exists at the same time

> Someone mentioned that we shouldn't use structs as name wrappers
> because that's against "D's philosophy" and it's working around the D
> module system. Well, the D module system might do a great job at
> protecting function hijacking, but wasting programmer time on name
> clashes could be as frustrating as hunting down a function hijack in
> some /lesser/ module system.
>
> That's my 2 cents..

I don't know who said but i agree it is wrong, not using the hack, but the  
need of a hack with the existence of a language feature for that purpose.
If we need a hack, we are in need of improving the feature.