On 02/15/2013 07:50 PM, Jeremy DeHaan wrote:

> 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

There may be other ways of achieving that and I haven't given much thought to your question but there is also the import expression:

  http://dlang.org/expression.html#ImportExpression

If needed, you can include D files similar to C's #include:

mixin (import ("part_of_my_module.d"));
mixin (import ("another_part_of_my_module.d"));

Ali

On Saturday, 16 February 2013 at 04:14:41 UTC, Ali Çehreli wrote:
> On 02/15/2013 07:50 PM, Jeremy DeHaan wrote:
>
> > 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
>
> There may be other ways of achieving that and I haven't given much thought to your question but there is also the import expression:
>
>   http://dlang.org/expression.html#ImportExpression
>
> If needed, you can include D files similar to C's #include:
>
> mixin (import ("part_of_my_module.d"));
> mixin (import ("another_part_of_my_module.d"));
>
> Ali

That is really cool! I'll look into this more, but I am using an IDE which would get angry if I included them in my project as .d files and didn't put in a module name, but I think you're on to something here.

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.

On Friday, February 15, 2013 20:14:41 Ali Çehreli wrote:
> On 02/15/2013 07:50 PM, Jeremy DeHaan wrote:
>  > 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
> 
> There may be other ways of achieving that and I haven't given much thought to your question but there is also the import expression:
> 
>    http://dlang.org/expression.html#ImportExpression
> 
> If needed, you can include D files similar to C's #include:
> 
> mixin (import ("part_of_my_module.d"));
> mixin (import ("another_part_of_my_module.d"));

You can play games like this if you really want to, but in general, it should be kept in mind that modules in D are designed to have a one-to-one correspondance with files, and packages are designed to have a one-to-one correspondance with directories. And in general, fighting that is just going to cause trouble and confusion. That doesn't necessarily mean that it should never be done, but in most cases, it would be far better to just reorganize your code so that it's not necessary. Also, AFAIK, mixing in imports is a very rare thing to do, so for the most part, people won't be expecting it, and it will likely cause maintenance issues for anyone else working on your project.

What is more typically done when you need to split stuff up is to use internal modules which are only imported internally and are not presented as part of the public API, but even that isn't terribly common, I don't think (but unlike mixing in imports, it's something that the standard library actually does in a few places).

- Jonathan M Davis

On 2013-02-16 05:14, Ali Çehreli wrote:

> mixin (import ("part_of_my_module.d"));
> mixin (import ("another_part_of_my_module.d"));

How is that better than public imports. You'll get access to private declarations but besides that.

-- 
/Jacob Carlborg

On 02/16/2013 04:58 AM, Jacob Carlborg wrote:
> On 2013-02-16 05:14, Ali Çehreli wrote:
>
>> mixin (import ("part_of_my_module.d"));
>> mixin (import ("another_part_of_my_module.d"));
>
> How is that better than public imports. You'll get access to private
> declarations but besides that.
>

I don't think it is better than any other solution. I got reminded of this possibility; that's all. :)

Ali

On 2013-02-16 15:12, Ali Çehreli wrote:

> I don't think it is better than any other solution. I got reminded of
> this possibility; that's all. :)

Fair enough. :)

-- 
/Jacob Carlborg

On 2013-02-16 05:19, Jeremy DeHaan wrote:

> That is really cool! I'll look into this more, but I am using an IDE
> which would get angry if I included them in my project as .d files and
> didn't put in a module name, but I think you're on to something here.

There's also template mixins that could help:

http://dlang.org/template-mixin.html

-- 
/Jacob Carlborg