Re: Packages / imports & references between modules
On 2019-04-28 16:18:59 +, 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
Re: Packages / imports & references between modules
On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote:
On 2019-04-28 11:44:03 +, 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;
}
Re: Packages / imports & references between modules
On 2019-04-28 11:44:03 +, 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
Re: Packages / imports & references between modules
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.
Re: Packages / imports & references between modules
On 2019-04-27 16:30:48 +, 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
Re: Packages / imports & references between modules
On 2019-04-27 16:30:48 +, 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
Re: Packages / imports & references between modules
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.
Re: Packages / imports & references between modules
On 2019-04-27 15:06:01 +, 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
Re: Packages / imports & references between modules
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.
Packages / imports & references between modules
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
