Working with modules

[Mike Parker]

On Saturday, 16 February 2013 at 03:50:12 UTC, Jeremy DeHaan 
wrote:
> I was actually going to post a similar question, but it looks 
> like this would be a better place to post!
>
> I know that a module can only be defined once, but I feel like 
> there could be times where it would be helpful to be able to 
> have the same module defined in separate files and I have an 
> example. Right now, I am working on a binding and I am making 
> use of the package access modifier to allow me to use internal 
> objects that the end user will not be able to access directly. 
> Problem is, my source files have many classes and are pretty 
> convoluted. If I could define the module more than once I could 
> split the source files up and it would be easier to work on, 
> but I would still be able to share package declared objects and 
> methods between modules like I do now. If I put the source 
> files into their own packages, they are now hidden from source 
> files I want them to be used in.
>
> Here's what I mean:
>
>
> mainpackage.system
> mainpackage.window
> mainpackage.graphics
>
> Anything defined with package is accessible between these.
>
> But...
> mainpackage.system.thing1
> mainpackage.system.thing2
> mainpackage.window.thing3
> etc...
>
> Now things defined as package in mainpackage.system.thing1 are 
> only accessible in mainpackage.system, but can't be accessed in 
> mainpackage.window.
>
> Thoughts?

On Saturday, 16 February 2013 at 03:50:12 UTC, Jeremy DeHaan
wrote:
> I was actually going to post a similar question, but it looks 
> like this would be a better place to post!
>
> I know that a module can only be defined once, but I feel like 
> there could be times where it would be helpful to be able to 
> have the same module defined in separate files and I have an 
> example. Right now, I am working on a binding and I am making 
> use of the package access modifier to allow me to use internal 
> objects that the end user will not be able to access directly. 
> Problem is, my source files have many classes and are pretty 
> convoluted. If I could define the module more than once I could 
> split the source files up and it would be easier to work on, 
> but I would still be able to share package declared objects and 
> methods between modules like I do now. If I put the source 
> files into their own packages, they are now hidden from source 
> files I want them to be used in.
>
> Here's what I mean:
>
>
> mainpackage.system
> mainpackage.window
> mainpackage.graphics
>
> Anything defined with package is accessible between these.
>
> But...
> mainpackage.system.thing1
> mainpackage.system.thing2
> mainpackage.window.thing3
> etc...
>
> Now things defined as package in mainpackage.system.thing1 are 
> only accessible in mainpackage.system, but can't be accessed in 
> mainpackage.window.
>
> Thoughts?

I see this as more of a code architecture issue. It's up to you
to decide which modules belong to which package, and that's that.
If you see system and window as belonging to one package, then
don't create subpackages. You can still split things up into
separate modules if you need to:

mainpackage.system
mainpackage.systhing1
mainpackage.systhing2
mainpackage.window
mainpackage.winthing3

You could keep your public-facing API in system and window or, if
your design doesn't work that way, have things spread out over
the various thing* modules and let system and window import them
publicly. Either way, client code then imports system and window
and pretends the rest don't exist.

It would be nice to have a special module declaration to enforce
this on the client side, something like:

private module mainpackage.systhing1;

Any module declared as such would not be importable outside of
the package, but could still be explicitly imported into the
namespace via a public import from another module in the same
package.