Is is possible to import all modules using something import a.b.*;?

I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.

On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
> Is is possible to import all modules using something import a.b.*;?
>
> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.


To be clear, I'd basically like to have one interface/class per file but a directory/folder is a sort of combined module as far as imports go.


e.g.,

/dir/a.d
/dir/b.d
/dir/c.d

could import a,b,c by using import dir or import dir.* instead of import a, b, c

each module has the same name as it's file.

On Wednesday, 17 July 2013 at 09:54:28 UTC, JS wrote:
> On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
>> Is is possible to import all modules using something import a.b.*;?
>>
>> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.
>
>
> To be clear, I'd basically like to have one interface/class per file but a directory/folder is a sort of combined module as far as imports go.
>
>
> e.g.,
>
> /dir/a.d
> /dir/b.d
> /dir/c.d
>
> could import a,b,c by using import dir or import dir.* instead of import a, b, c
>
> each module has the same name as it's file.

I imagine a string mixin could be used if necessary but I'm hoping there is a better way.

On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
> Is is possible to import all modules using something import a.b.*;?
>
> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.

I *think* that if you use a boost like scheme, you can do it. I'd look like this:

+
+ a.d
+ a //Dir
+-+ b.d
  + c.d

Where a.d contains:
//----
public import a.b, a.c;
//----

It requries a bit of maintenance though.
It work for me, although I think there are open bugs about this in regards to conflicting modules/packages.

For example, testing this, it works with dmd, but it fails for me with rdmd...

On Wednesday, 17 July 2013 at 09:57:04 UTC, monarch_dodra wrote:
> On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
>> Is is possible to import all modules using something import a.b.*;?
>>
>> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.
>
> I *think* that if you use a boost like scheme, you can do it. I'd look like this:
>
> +
> + a.d
> + a //Dir
> +-+ b.d
>   + c.d
>
> Where a.d contains:
> //----
> public import a.b, a.c;
> //----
>
> It requries a bit of maintenance though.
> It work for me, although I think there are open bugs about this in regards to conflicting modules/packages.
>
> For example, testing this, it works with dmd, but it fails for me with rdmd...

so you are saying that by using public import it will make all imports of imports available?

e.g.,

a.d
public import a.b, a.c;

test.d
import a; // will also import a.b and a.c?

On Wednesday, 17 July 2013 at 10:04:53 UTC, JS wrote:
> On Wednesday, 17 July 2013 at 09:57:04 UTC, monarch_dodra wrote:
>> On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
>>> Is is possible to import all modules using something import a.b.*;?
>>>
>>> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.
>>
>> I *think* that if you use a boost like scheme, you can do it. I'd look like this:
>>
>> +
>> + a.d
>> + a //Dir
>> +-+ b.d
>>  + c.d
>>
>> Where a.d contains:
>> //----
>> public import a.b, a.c;
>> //----
>>
>> It requries a bit of maintenance though.
>> It work for me, although I think there are open bugs about this in regards to conflicting modules/packages.
>>
>> For example, testing this, it works with dmd, but it fails for me with rdmd...
>
> so you are saying that by using public import it will make all imports of imports available?
>
> e.g.,
>
> a.d
> public import a.b, a.c;
>
> test.d
> import a; // will also import a.b and a.c?

Yes, that should be it. Note, however, that a simple "public import" will *also* import the imported "module" as if it was inside, eg:

//===============================
//a.b.d:
module a.b;
void foo();

//a.c.d:
module a.c;
void bar();

//main.d
import a;
void main()
{
    foo(); //OK
    bar(); //OK
    a.foo(); //OK (!!!)
    a.bar(); //OK (!!!)
    a.b.foo(); //OK
    a.c.bar(); //OK
}
//===============================

To be frank, I don't know if this is a bug, or a feature...

On Wednesday, July 17, 2013 11:34:56 JS wrote:
> Is is possible to import all modules using something import a.b.*;?
> 
> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.

This has been implemented in git master:

http://wiki.dlang.org/DIP37

- Jonathan M Davis

On Wednesday, 17 July 2013 at 11:45:09 UTC, monarch_dodra wrote:
> //main.d
> import a;
> void main()
> {
>     foo(); //OK
>     bar(); //OK
>     a.foo(); //OK (!!!)
>     a.bar(); //OK (!!!)
>     a.b.foo(); //OK
>     a.c.bar(); //OK
> }
> //===============================
>
> To be frank, I don't know if this is a bug, or a feature...

Public import adds the symbols to the module and makes them public, by default they are private.

    foo();
    a.foo();

These are equivalent since a contains the symbols of b. This is has the annoyance:

    import a, b;

    foo() // Ambiguous a.foo and b.foo()

On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis wrote:
> On Wednesday, July 17, 2013 11:34:56 JS wrote:
>> Is is possible to import all modules using something import
>> a.b.*;?
>> 
>> I'd like to partition some modules up into smaller pieces to
>> simplify modification(reduce scrolling) but, of course, this
>> increases the number of imports drastically.
>
> This has been implemented in git master:
>
> http://wiki.dlang.org/DIP37
>
> - Jonathan M Davis

Thanks, I've updated the compiler to 2.063.2 and made my hierarchy like

lib/package.d
lib/mod.d
lib/dir1/package.d
lib/dir1/a.d
lib/dir1/b.d
lib/dir2/package.d
lib/dir2/c.d

each package.d file publically imports all sub packages(by chaining package imports and importing same directory modules):

lib/package.d:
module Package;
public import mod.d;
public import dir1.Package;
public import dir2.Package;

lib/dir1/package.d;
module dir1.Package;
public import dir1.a;
public import dir2.b;


etc....

This should allow me to import any resolution I need. e.g., if I want the whole library I just import lib/package.d.


When I do this dmd can't find my module files.

I have only included the root dir(lib) in sc.ini, hopefully I do not need to include every single subdirectory in lib for it to work ;/ ? (this would be better to be auto generated)

On Thursday, July 18, 2013 08:45:25 JS wrote:
> On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis
> 
> wrote:
> > On Wednesday, July 17, 2013 11:34:56 JS wrote:
> >> Is is possible to import all modules using something import a.b.*;?
> >> 
> >> I'd like to partition some modules up into smaller pieces to simplify modification(reduce scrolling) but, of course, this increases the number of imports drastically.
> > 
> > This has been implemented in git master:
> > 
> > http://wiki.dlang.org/DIP37
> > 
> > - Jonathan M Davis
> 
> Thanks, I've updated the compiler to 2.063.2 and made my hierarchy like
> 
> lib/package.d
> lib/mod.d
> lib/dir1/package.d
> lib/dir1/a.d
> lib/dir1/b.d
> lib/dir2/package.d
> lib/dir2/c.d
> 
> each package.d file publically imports all sub packages(by chaining package imports and importing same directory modules):
> 
> lib/package.d:
> module Package;
> public import mod.d;
> public import dir1.Package;
> public import dir2.Package;
> 
> lib/dir1/package.d;
> module dir1.Package;
> public import dir1.a;
> public import dir2.b;
> 
> 
> etc....
> 
> This should allow me to import any resolution I need. e.g., if I want the whole library I just import lib/package.d.
> 
> 
> When I do this dmd can't find my module files.
> 
> I have only included the root dir(lib) in sc.ini, hopefully I do
> not need to include every single subdirectory in lib for it to
> work ;/ ? (this would be better to be auto generated)

Normally, nothing like that has any business in sc.ini. sc.ini is supposed to be for the standard stuff, not your personal stuff. You should be passing it to the compiler using the appropriate compiler flags (-I in this case IIRC). Now, you obviously _can_ stick it all in your sc.ini file you want to, but I believe that that would generally be considered bad practice.

As for your actual files, you're making several mistakes.

1. It's not module Package. Not only is it generally considered bad practice to use any uppercase letters in a module or package name, but the module name for a package.d file does not include package. So, for instance, if std.datetime were a package with std/datetime/package.d in it, then that package.d file would have module std.datetime; at the top.

2. Maybe it's just a typo, but you have some imports which end with .d, which isn't legal.

3. A top-level package.d won't work. There's no name to give it to import and no name to give its module declaration. Also, I don't believe that the top level is considered a package in the first place. I believe that the only reason the package modifer works on the top level is the fact that package is outright broken right now ( http://d.puremagic.com/issues/show_bug.cgi?id=143 ) and is pretty much treated as public. Once that's been fixed, any attempt at using package at the top level will fail.

I might be missing something else, but I think that your main problem is how you name the module declarations in your package.d files.

- Jonathan M Davis