Re:C++ Modules Might Be Dead-On-Arrival
by ben-schaaf on Monday January 28, 2019 @04:33AM
(#19016189)
D also has package.d for the same effect as python. It works quite well as package is a keyword and thus can't be used as a regular module anyway.
But package.d could lead you to overdepend on too many modules too :) it's mostly great for end applications rather than internal to libraries.
Re:C++ Modules Might Be Dead-On-Arrival
by ben-schaaf on Monday January 28, 2019 @09:46AM
(#19017745)
Sure, but that's not specific to package.d. See the earlier convention of all.d or d.d. That's the trade-off with having public imports. I don't see how this is related to my comment though?
Re:C++ Modules Might Be Dead-On-Arrival
by JoshTriplett on Monday January 28, 2019 @07:40AM
(#19016980)
> The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory:
> import A -- compiler reads A.hs
> import A.B -- compiler reads A/B.hs
That has to happen at some level, assuming subdirectories; otherwise, what would "import A.B.C" refer to?
Python, IMO, handles this correctly by having __init__.py support inside directories. It's theoretically less elegant because of the special name, but in practice leads to better file organization.
Same for Rust, but even better, because one can define nested modules in the same file. So you can either define a new module in the same file, put it in a different file named by the module, or put it in the file `mod.rs` inside the directory named by the module.