Packages / imports & references between modules
Robert M. Münch
robert.muench at saphirion.com
Sun Apr 28 11:00:45 UTC 2019
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
More information about the Digitalmars-d-learn
mailing list