www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - selective import adds symbol to public namespace

reply Myron Alexander <someone somewhere.com> writes:
Hello.

When I import a symbol from a module into my module using the selective 
import, the symbol as added to the public namespace such that modules 
that import my module inherit that symbol as well.

I have attached two source files 'modulea.d' and 'moduleb.d' where the 
selective import of toString is visible to moduleb. A straight import 
without selective is private. To test the case, compile moduleb.d with 
'dmd -c moduleb.d'.

This means all selective imports will pollute the namespace making 
catching dependency issues a little harder. Also, there is the problem 
of name conflicts and unexpected overloads.

I have discovered the same problem with declaring aliases in modules 
that are supposed to be conveniences for the module but not intended to 
be part of the import symbol list. Same for private structures and 
private classes. It seems that the concept of private in a module is 
pretty much non-existent thus name conflicts will be an issue.

Is this a bug, or is this intentional. What is Walter's position on this 
and should I log a bug report?

BTW, I consider this problem a very serious one. It may not seem like 
one now, but as the code-base grows, this will be a problem; much like 
how #include got out of hand.

Thanks ahead,

Myron.
Sep 19 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Myron Alexander wrote:

 Hello.
 
 When I import a symbol from a module into my module using the selective 
 import, the symbol as added to the public namespace such that modules 
 that import my module inherit that symbol as well.
 
 I have attached two source files 'modulea.d' and 'moduleb.d' where the 
 selective import of toString is visible to moduleb. A straight import 
 without selective is private. To test the case, compile moduleb.d with 
 'dmd -c moduleb.d'.
 
 This means all selective imports will pollute the namespace making 
 catching dependency issues a little harder. Also, there is the problem 
 of name conflicts and unexpected overloads.
 
 I have discovered the same problem with declaring aliases in modules 
 that are supposed to be conveniences for the module but not intended to 
 be part of the import symbol list. Same for private structures and 
 private classes. It seems that the concept of private in a module is 
 pretty much non-existent thus name conflicts will be an issue.
 
 Is this a bug, or is this intentional. What is Walter's position on this 
 and should I log a bug report?
 
 BTW, I consider this problem a very serious one. It may not seem like 
 one now, but as the code-base grows, this will be a problem; much like 
 how #include got out of hand.
 
 Thanks ahead,
 
 Myron.
 


Sounds a lot like the infamous and oft-reported bugs 313/314:
http://d.puremagic.com/issues/show_bug.cgi?id=313
http://d.puremagic.com/issues/show_bug.cgi?id=314

--bb
Sep 19 2007
parent Myron Alexander <someone somewhere.com> writes:
Bill Baxter wrote:

 Sounds a lot like the infamous and oft-reported bugs 313/314:
 http://d.puremagic.com/issues/show_bug.cgi?id=313
 http://d.puremagic.com/issues/show_bug.cgi?id=314
 
 --bb


Ahh. Thanks for the heads up.

Regards,

Myron.
Sep 19 2007