www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - namespaces and modules

reply MicroWizard <MicroWizard_member pathlink.com> writes:
Could anybody be so kind to explain how import and private import
really work in a big project?

In a project where I use ten source files there are hierarchical dependencies,
so the files import each others.
Nowadays I needed some common Phobos functions also. (ex. std.string)
I had to insert private imports.

The result is that the compiler reports conflicts between completely independent
source module's imports.

My question is: How could two "private import" statements conflict at all?
What does private mean???

Thanks for advance,
Tamas Nagy
Apr 16 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"MicroWizard" <MicroWizard_member pathlink.com> wrote in message 
news:d3s844$iso$1 digitaldaemon.com...
 Could anybody be so kind to explain how import and private import
 really work in a big project?

 In a project where I use ten source files there are hierarchical 
 dependencies,
 so the files import each others.
 Nowadays I needed some common Phobos functions also. (ex. std.string)
 I had to insert private imports.

 The result is that the compiler reports conflicts between completely 
 independent
 source module's imports.

 My question is: How could two "private import" statements conflict at all?
 What does private mean???

 Thanks for advance,
 Tamas Nagy

It would help to have a more concrete example, but in general it seems best to private import whenever possible. You won't notice any difference between private import and public import within the module with the import statement (say module A) but the difference is crucial to the modules that import A. For example if moduleA and moduleB look like moduleA: import bad1; import bad2; module B: import moduleA; then B will see all the symbols in bad1 and bad2 in the top-level scope and is much more likely to get conflicts. If instead moduleA looked like moduleA: private import bad1; private import bad2; then B wouldn't see the symbols in bad1 and bad2 in the top-level scope and so conflicts are less likely. It doesn't take a very complex project before one gets bitten by these clashes. Unfortunately I think the error message for the conflict doesn't give the chain of imports that resulted in the symbol getting into the global scope, but some day that will improve (hopefully). It can be hard to figure out exactly why a given symbol is in the top-level scope. One technique in tracking down the cuplrit is to use the form private import bad1; instead of private { import bad1; } and then grep for "import". The public one that should be private sometimes pops out quickly just by doing that. Otherwise you'll probably have to starting tossing in 'private' untill you narrow it down.
Apr 17 2005
parent MicroWizard <MicroWizard_member pathlink.com> writes:
Thanks a lot.

Finally I drew a hierarchy of files and it made
the definition of imports a lot easier.
Of course there was some ambiguity. After minimization
the project compiles and works as before.

The experiences:
- The compiler does not recognize namespace ambiguities
__before__ a reference occures to an ambiguous item.
- The compiler could not show the root of this (hopefully yet).

It could be improved somehow.
(I use D, because it reveals my errors very fast. Unfortunately not in this
case.)

Thanks again,
Tamas Nagy

In article <d3tvmg$1tdb$1 digitaldaemon.com>, Ben Hinkle says...
"MicroWizard" <MicroWizard_member pathlink.com> wrote in message 
news:d3s844$iso$1 digitaldaemon.com...
 Could anybody be so kind to explain how import and private import
 really work in a big project?

 In a project where I use ten source files there are hierarchical 
 dependencies,
 so the files import each others.
 Nowadays I needed some common Phobos functions also. (ex. std.string)
 I had to insert private imports.

 The result is that the compiler reports conflicts between completely 
 independent
 source module's imports.

 My question is: How could two "private import" statements conflict at all?
 What does private mean???

 Thanks for advance,
 Tamas Nagy

It would help to have a more concrete example, but in general it seems best to private import whenever possible. You won't notice any difference between private import and public import within the module with the import statement (say module A) but the difference is crucial to the modules that import A. For example if moduleA and moduleB look like moduleA: import bad1; import bad2; module B: import moduleA; then B will see all the symbols in bad1 and bad2 in the top-level scope and is much more likely to get conflicts. If instead moduleA looked like moduleA: private import bad1; private import bad2; then B wouldn't see the symbols in bad1 and bad2 in the top-level scope and so conflicts are less likely. It doesn't take a very complex project before one gets bitten by these clashes. Unfortunately I think the error message for the conflict doesn't give the chain of imports that resulted in the symbol getting into the global scope, but some day that will improve (hopefully). It can be hard to figure out exactly why a given symbol is in the top-level scope. One technique in tracking down the cuplrit is to use the form private import bad1; instead of private { import bad1; } and then grep for "import". The public one that should be private sometimes pops out quickly just by doing that. Otherwise you'll probably have to starting tossing in 'private' untill you narrow it down.

Apr 19 2005