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
