• MicroWizard (12/12) Apr 16 2005 Could anybody be so kind to explain how import and private import
• Ben Hinkle (33/47) Apr 17 2005 It would help to have a more concrete example, but in general it seems b...
• MicroWizard (15/68) Apr 19 2005 Thanks a lot.

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

"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. 

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.