www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - nested module problem

reply Jean-Louis Leroy <jl leroy.nyc> writes:
So I have:

jll ORAC:~/dev/d/tests/modules$ tree
.
├── foo
│   └── bar.d
└── foo.d

foo.d contains:
import foo.bar;

bar.d is empty.

Now I try compiling:
jll ORAC:~/dev/d/tests/modules$ dmd -c foo.d
jll ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d

So far so good. Now I try it the way dub does it:
jll ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
foo.d(1): Error: module bar from file foo/bar.d must be imported 
with 'import bar;'

What's up?
Sep 02
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy 
wrote:
 So I have:

 jll ORAC:~/dev/d/tests/modules$ tree
 .
 ├── foo
 │   └── bar.d
 └── foo.d

 foo.d contains:
 import foo.bar;

 bar.d is empty.
This means bar.d's module name will be inferred by the compiler [1], which will ignore the path you put it under, yielding the module name "bar", not "foo.bar" (one of the issues of doing otherwise would be how the compiler should know at which path depth the inference should start - and any solution to that other than simply ignoring the path would be full of special cases):
 Modules have a one-to-one correspondence with source files. 
 The module name is, by default, the file name with the path 
 and extension stripped off, and can be set explicitly with the 
 module declaration.
 Now I try compiling:
 jll ORAC:~/dev/d/tests/modules$ dmd -c foo.d
This looks like a compiler bug to me (accepts invalid), though I'm not certain.
 jll ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d
(No issue here, just an empty module being compiled separately)
 So far so good. Now I try it the way dub does it:
 jll ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
 foo.d(1): Error: module bar from file foo/bar.d must be 
 imported with 'import bar;'

 What's up?
This doesn't work, because of the inferred module name for foo/bar.d being "bar". So the compiler wants you to import it by the name it has inferred for you (The fix being either specifying the module name in foo/bar.d as `module foo.bar`, or importing it as via `import bar;` in foo.d). [1] https://dlang.org/spec/module.html
Sep 02
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner 
wrote:
 So the compiler wants you to import it by the name it has 
 inferred for you (The fix being either specifying the module 
 name in foo/bar.d as `module foo.bar`, or importing it as via 
 `import bar;` in foo.d).
 [1] https://dlang.org/spec/module.html
I thought of doing that, it merely changed the error. OK now I have: in foo.d: module foo; import foo.bar; in foo/bar.d: module foo.bar; $ dmd -c foo.d foo/bar.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d If I compile separately: jll ORAC:~/dev/d/tests/modules$ dmd -I. -c foo.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d jll ORAC:~/dev/d/tests/modules$ dmd -I. -c foo/bar.d It believes that 'foo' is a package...because there is a 'foo' directory? I see that a workaround is to move foo.d to foo/package.d but I would like to avoid that.
Sep 02
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy 
wrote:
 On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner 
 wrote:
 So the compiler wants you to import it by the name it has 
 inferred for you (The fix being either specifying the module 
 name in foo/bar.d as `module foo.bar`, or importing it as via 
 `import bar;` in foo.d).
 [1] https://dlang.org/spec/module.html
I thought of doing that, it merely changed the error. OK now I have: in foo.d: module foo; import foo.bar; in foo/bar.d: module foo.bar; $ dmd -c foo.d foo/bar.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d If I compile separately: jll ORAC:~/dev/d/tests/modules$ dmd -I. -c foo.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d
Yes, these now both fail because you cannot have a module `foo` and a package `foo` at the same time (they share a namespace), I forgot about that.
 jll ORAC:~/dev/d/tests/modules$ dmd -I. -c foo/bar.d
(same as before, no issue here)
 It believes that 'foo' is a package...because there is a 'foo' 
 directory?
You created the 'foo' package by specifying `module foo.bar` in foo/bar.d.
 I see that a workaround is to move foo.d to foo/package.d but I 
 would like to avoid that.
AFAIK you can't; consider: -- baz.d --- import foo; ------------ in the same directory as foo.d. If foo/package.d exists (with `module foo` inside), what should baz.d import? foo.d or foo/package.d? The point being that we could have either used foo/package.d or foo.d for a package file, but not both (as that would allow ambiguity) and package.d was chosen. [1] https://dlang.org/spec/module.html#package-module
Sep 02
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
On Saturday, 2 September 2017 at 21:42:59 UTC, Moritz Maxeiner 
wrote:
 On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy 
 wrote:
 [...]
Yes, these now both fail because you cannot have a module `foo` and a package `foo` at the same time (they share a namespace), I forgot about that.
 [...]
(same as before, no issue here)
 [...]
You created the 'foo' package by specifying `module foo.bar` in foo/bar.d.
 [...]
AFAIK you can't; consider: -- baz.d --- import foo; ------------ in the same directory as foo.d. If foo/package.d exists (with `module foo` inside), what should baz.d import? foo.d or foo/package.d? The point being that we could have either used foo/package.d or foo.d for a package file, but not both (as that would allow ambiguity) and package.d was chosen. [1] https://dlang.org/spec/module.html#package-module
Hmmm I see...I was thinking of spinning the runtime part of my openmethods library into its own module (like here https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...
Sep 02
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy 
wrote:
 [...]

 Hmmm I see...I was thinking of spinning the runtime part of my 
 openmethods library into its own module (like here 
 https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods)
but it looks like a bad idea...
Why does it look like a bad idea (I don't see an immediate issue the module structure either way)?
Sep 02
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 2 September 2017 at 23:02:18 UTC, Moritz Maxeiner 
wrote:
 On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy 
 wrote:
 [...]

 Hmmm I see...I was thinking of spinning the runtime part of my 
 openmethods library into its own module (like here 
 https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods)
but it looks like a bad idea...
Why does it look like a bad idea (I don't see an immediate issue the module structure either way)?
* in the module structure
Sep 02