public import and bugs it causes

[Steven Schveighoffer]

On Fri, 14 May 2010 21:19:38 -0400, Alex Makhotin <alex at bitprox.com> wrote:

> Walter Bright wrote:
>> You can import only those names you wish. See static imports, renamed  
>> imports and selective imports in  
>> http://www.digitalmars.com/d/2.0/module.html
>
> OK, 'static import' combination seems to force use of fully qualified  
> name. Requires a lot of typing of the fully names for imported classes.
> A lot of typing only for the sake of one global variable.
>
> The renamed import also requires countless typing using the renamed  
> prefix.
>
> The specific imports require me to select what to import(again all the  
> work on me, not the tool I use). Oh no. Every time I desire to use some  
> member of the import I type 'import module : memberiwant'.

You are blowing this way out of proportion.  I don't ever remember having  
to rename or statically import std.stdio.  D's default is to import all  
names into your local namespace, that is good enough 99% of the time.   
Sometimes you need to rename things, or force static resolution.  In those  
cases, the tools are there.

But you want to require globals to be referred to by fully qualified  
names?  How does it sound that you have to write std.stdio.writeln every  
time you want to write something?

The problem as I see it is that std.compiler has a poorly named global  
variable.  You can rename that variable when importing, lessening your  
pain, or you can statically import it, making your job a little more  
difficult, but more precise.  Or you can get the author to change it.   
There are several options, and all of them seem way way more attractive  
than ruining the syntax for the rest of the well-named module globals.   
'name' just is a single bad global name, it does not make all globals  
badly named.

> As far as I know the C# hasn't such complications, why should D?

C# sucks when importing conflicting names.  I've dealt with it, and you  
simply have to refer to the fully qualified name to be unambiguous.  With  
D, I can rename the less used one at import time to only have to rewrite  
some of them.  This does not ruin the experience for anyone else who uses  
only one of the modules.  Note that D refuses to compile ambiguous  
symbols, so the problem is not that it blindly chooses one.

You also have to refer to all functions and symbols inside a class, if  
it's not the class you are writing.  Without the IDE, this would be  
torture.  A good example is writing output -- Console.WriteLine(x).  I'll  
take writeln(x) any day over that.

C# is not the model to follow.

-Steve