www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Packages / imports & references between modules

reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
A/a.d has  module A.a;
A/b.d has  module A.b;

A/package.d
	import A.a;
	import A.b;

A.b needs to access something from A.a

I assumed if I do

	import package.d

that A.b sees the content of A.a now and doens't need an explicit line with

a/b.d
	import A.a;

But this doesn't seem to be the case. Or am I missing something?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 27 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:

 	import A.a;


`import` by itself is a private import, meaning it cannot be seen 
from outside the module.

Make it `public import` and it can be seen from the outside; the 
other modules importing it can access them too.
Apr 27 2019
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-04-27 15:06:01 +0000, Adam D. Ruppe said:


 On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:

 	import A.a;


 
 `import` by itself is a private import, meaning it cannot be seen from 
 outside the module.
 
 Make it `public import` and it can be seen from the outside; the other 
 modules importing it can access them too.


I thought that public only applies to the upward chain, not to the same level.

However, using public doens't help as there are still some undefined 
identifiers between modules on the same level. I think I need to 
elaborate on my case a bit more:

I use DStep to convert some C library headers. And these use forward 
references to structs.

A/a.d
	module A.a;
	struct myStruct;

A/b.d
	module A.b;
	struct myStruct {...}

A/c.d
	module A.c;
	struct myOtherStruct {
		myStruct ms;
	}

A/package.d
	import A.a;
	import A.b;
	import A.c;

I get an "undefined identifier" error in A/c.d for myStruct. Changing A/c.d to:

A/c.d
	module A.c;
	import A.b;
	struct myOtherStruct {
		myStruct ms;
	}

works. But this would end up in adding a lot of imports to avoid the 
"undefined identifier" problem to many files manually and somehow break 
the DStep workflow.

So, is there a way to avoid this? With public import it doesn't seem to work.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 27 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote:

 I thought that public only applies to the upward chain, not to 
 the same level.


There is no "same level" really (except for the `package` 
protection level); it is just inside the module or outside the 
module for imports.

But I see what you are doing now...


 A/c.d
 	module A.c;
 	struct myOtherStruct {
 		myStruct ms;
 	}


This will never work in D. The module needs to work by itself. It 
can see public imports from another module it itself imports:

module A.c;

import A; // thanks to this, it can see a `public import A.a;` 
from the A package..


But without that explicit import, it cannot see anything outside 
itself.


You might be able to get away with listing the `public import`s 
in package.d, and then just `import A;` in each individual module 
though.

But it won't just inherit stuff from other modules, like C's 
#include does. A D module is parsed independently of other 
modules.


 works. But this would end up in adding a lot of imports to 
 avoid the "undefined identifier" problem to many files manually 
 and somehow break the DStep workflow.


maybe dstep could automatically add imports to generated files 
too.
Apr 27 2019
next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-04-27 16:30:48 +0000, Adam D. Ruppe said:


 There is no "same level" really (except for the `package` protection 
 level); it is just inside the module or outside the module for imports.


Hi Adamn, ok, got it. The docs are indicating that the "public import" 
is only working along the nested import chain. Maybe it's possible to 
make this much more clear? I don't know how to submit doc enhancements 
or a comment what should be enhanced.


 But I see what you are doing now...
 

 A/c.d
 	module A.c;
 	struct myOtherStruct {
 		myStruct ms;
 	}


 
 This will never work in D. The module needs to work by itself. It can 
 see public imports from another module it itself imports:


Aha, that was the missing link for me.


 module A.c;
 
 import A; // thanks to this, it can see a `public import A.a;` from the 
 A package..



Ok, at least I can use such a simple full package import. Are there are 
any disadvantages when I just import everything?


 But without that explicit import, it cannot see anything outside itself.


Ok.


 You might be able to get away with listing the `public import`s in 
 package.d, and then just `import A;` in each individual module though.


Yes, going to check that option.


 But it won't just inherit stuff from other modules, like C's #include 
 does. A D module is parsed independently of other modules.


Got it.


 maybe dstep could automatically add imports to generated files too.


Going to submit an issue for this. Thanks for your answer, helps a lot.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 28 2019
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-04-27 16:30:48 +0000, Adam D. Ruppe said:


 This will never work in D. The module needs to work by itself. It can 
 see public imports from another module it itself imports:
 
 module A.c;
 
 import A; // thanks to this, it can see a `public import A.a;` from the 
 A package..
 
 
 But without that explicit import, it cannot see anything outside 
 itself. You might be able to get away with listing the `public import`s 
 in package.d, and then just `import A;` in each individual module 
 though.


One more problem now showing up, when I do this:

A/a.d
	module A.a;
	struct myStruct;

A/b.d
	module A.b;
	struct myStruct {...}

A/c.d
	module A.c;
	import A;
	struct myOtherStruct {
		myStruct ms;
	}

I now get an error in file A/c.d that a.a.myStruct conflicts with 
a.b.myStruct. Looks like these symbols are different for D. Is there a 
way to tell D that one is only a forward reference and is the same when 
D sees the struct declaration later?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 28 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote:


 One more problem now showing up, when I do this:

 A/a.d
 	module A.a;
 	struct myStruct;

 A/b.d
 	module A.b;
 	struct myStruct {...}

 A/c.d
 	module A.c;
 	import A;
 	struct myOtherStruct {
 		myStruct ms;
 	}

 I now get an error in file A/c.d that a.a.myStruct conflicts 
 with a.b.myStruct. Looks like these symbols are different for 
 D. Is there a way to tell D that one is only a forward 
 reference and is the same when D sees the struct declaration 
 later?


They're different symbols because they're in different modules. 
The module and package name is part of the symbol name. Just 
import A.b in A.a.
Apr 28 2019
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-04-28 11:44:03 +0000, Mike Parker said:


 They're different symbols because they're in different modules. The 
 module and package name is part of the symbol name.


Ok, that's what I assumed too.


  Just import A.b in A.a.


Won't help. I just commented the lines DStep generated for forward 
referenced structs.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 28 2019
parent reply kdevel <kdevel vogtner.de> writes:
On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote:

 On 2019-04-28 11:44:03 +0000, Mike Parker said:


 They're different symbols because they're in different 
 modules. The module and package name is part of the symbol 
 name.


 Ok, that's what I assumed too.


  Just import A.b in A.a.


 Won't help. I just commented the lines DStep generated for 
 forward referenced structs.


This compiles with dmd v2.085.1:

$ cat A/a.d
module A.a;
import A.b;

$ cat A/b.d
module A.b;
struct myStruct {
    int i;
}

$ cat A/c.d
module A.c;
import A.a;
import A.b;

struct myOtherStruct {
    myStruct ms;
}

void main ()
{
    import std.stdio;
    myOtherStruct mos;
    mos.writeln;
}
Apr 28 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-04-28 16:18:59 +0000, kdevel said:


 This compiles with dmd v2.085.1:
 
 $ cat A/a.d
 module A.a;
 import A.b;
 
 $ cat A/b.d
 module A.b;
 struct myStruct {
     int i;
 }
 
 $ cat A/c.d
 module A.c;
 import A.a;
 import A.b;
 
 struct myOtherStruct {
     myStruct ms;
 }
 
 void main ()
 {
     import std.stdio;
     myOtherStruct mos;
     mos.writeln;
 }


Yes, as long as you are adding the imports all over, things can work. 
But as said, if you creating bindings for a larger C library, this is 
not practicable.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Apr 28 2019