public import and bugs it causes

[Alex Makhotin]

Walter Bright wrote:
> That's up to the author of TestM1. If he doesn't want the names in 
> TestM2 to be visible, he should privately import TestM2.

That requires the access to the source code or the desire of the author 
of the third party library. What if I don't have that? Deal with bugs or 
abandon the use of the library. I would choose to abandon.

I generated the headers:

> // D import file generated from 'TestM2.d'
> module Server.TestM2;
> const 
> {
>     string name = "New Name";
> }

> // D import file generated from 'TestM1.d'
> module Server.TestM1;
> public 
> {
>     import Server.TestM2;
> }


I don't want to tolerate the unnecessary global variable 'name' in my 
code when I privately import the Server.TestM1 module. And whatever 
other countless unnecessary global variables the author of that(closed 
source, commercial) module leaved for me.

My proposal for fixing this are:

1. Require the fully qualified path to the member of the module. To be 
able to operate with the variable 'name' the user should access it 
explicitly as 'Server.TestM2.name'.
2. Require the user of the imported third party module to explicitly 
import module Server.TestM2 to be able to use simple access method 
without the namespace prefix.
3. The D compiler must warn about the use of the global variable from 
the public import module.
4. Extreme case would be to get rid of globals which as a I understand 
is not possible.

-- 
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com