www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Import all?

reply "JS" <js.mdnq gmail.com> writes:
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.
Jul 17 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
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.
Jul 17 2013
parent "JS" <js.mdnq gmail.com> writes:
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.
Jul 17 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
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...
Jul 17 2013
parent reply "JS" <js.mdnq gmail.com> writes:
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?
Jul 17 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
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...
Jul 17 2013
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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()
Jul 17 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jul 17 2013
parent reply "JS" <js.mdnq gmail.com> writes:
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)
Jul 17 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 18 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 18 July 2013 at 07:16:35 UTC, Jonathan M Davis wrote:
 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.
I intentionally chose uppercase because it is more informative. I am not worried about cross-compilation issues at this point. iPackage.d looks nicer than ipackage.d. I did add Package to the end of module names and did uppercase package.d, possibly that is part of thep roblem.
 2. Maybe it's just a typo, but you have some imports which end 
 with .d, which
 isn't legal.
yes
 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
I'll probably have to setup visual d to insert the includes dirs on the command line. I had the same issue before when trying to include modules and edited sc.ini to get it to work. As far as I can tell, there is no way to set global includes in visual d which is why I used sc.ini. (I don't want to setup the includes directory for each project I create) In any case, the real question I have is: Does dmd require each directory for each module to be included by -I? Or is the base directory good enough and package resolution will get at the sub directories?
Jul 18 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, July 18, 2013 09:25:46 JS wrote:
 In any case, the real question I have is: Does dmd require each
 directory for each module to be included by -I? Or is the base
 directory good enough and package resolution will get at the sub
 directories?
The base directory of each package hierarchy must be passed to dmd with -I. So, if you have the module abc.foo.bar, then dmd must have been passed the directory that abc is in. A module's fully qualified name is its directory hierarchy, and dmd is always looking for the base of the hierarchy, so you give it each directory which is the root of a package hierarchy. If you have abc.foo.bar, and you passed it the abc or abc/foo, it would then effectively be looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d. - Jonathan M Davis
Jul 18 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 18 July 2013 at 07:43:33 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 09:25:46 JS wrote:
 In any case, the real question I have is: Does dmd require each
 directory for each module to be included by -I? Or is the base
 directory good enough and package resolution will get at the 
 sub
 directories?
The base directory of each package hierarchy must be passed to dmd with -I. So, if you have the module abc.foo.bar, then dmd must have been passed the directory that abc is in. A module's fully qualified name is its directory hierarchy, and dmd is always looking for the base of the hierarchy, so you give it each directory which is the root of a package hierarchy. If you have abc.foo.bar, and you passed it the abc or abc/foo, it would then effectively be looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d. - Jonathan M Davis
using All instead of package as the name worked really well, I can easily chain imports and each module can import the root to import the whole library. e.g., lib/All.d lib/modules*.d lib/dir?/.../dir?/modules*.d each module only has to import All to get access to the whole library. Only the final directories need to import each module. Each internal directory just has to import the All.d's of each subdirectory and any modules in the same directory. Seems to work really well and very simple to update and include various parts of the library. e.g., /all.d /a.d /dir/all.d /dir/b.d all.d: module all; public import a; public import dir.b; /dir/all.d module dir.all; public import dir.b; (I do have my lib partitions for different libraries I have something like import mylib.all) essentially all acts like *. e.g., import dir.*; is the same as import dir.all; (except * would automatically import everything for you making life easier).
Jul 18 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, July 18, 2013 10:10:13 JS wrote:
 using All instead of package as the name worked really well, I
 can easily chain imports and each module can import the root to
 import the whole library.
Yes. You can do that, though again I'd point out that using uppercase letters in module and package names is generally frowned upon. That's just how public import works, and plenty of folks have had all.d files in their projects for years now. None of that requires a new version of dmd. The key thing about the DIP (which _does_ require_ the git version of dmd) is that it allows you to import the package as if it were a module. This will allow us to do things like split up std.datetime or std.algorithm in place without breaking anyone's code, as import std.datetime or import std.algorithm would continue to work as they had as long as their package.d files publicly imported everything that had been in those modules before. I would expect that in the long term, package.d will supplant all.d completely, but you're obviously free to use it all.d if you want to. - Jonathan M Davis
Jul 18 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 18 July 2013 at 08:50:34 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 10:10:13 JS wrote:
 using All instead of package as the name worked really well, I
 can easily chain imports and each module can import the root to
 import the whole library.
Yes. You can do that, though again I'd point out that using uppercase letters in module and package names is generally frowned upon. That's just how public import works, and plenty of folks have had all.d files in their projects for years now. None of that requires a new version of dmd. The key thing about the DIP (which _does_ require_ the git version of dmd) is that it allows you to import the package as if it were a module. This will allow us to do things like split up std.datetime or std.algorithm in place without breaking anyone's code, as import std.datetime or import std.algorithm would continue to work as they had as long as their package.d files publicly imported everything that had been in those modules before. I would expect that in the long term, package.d will supplant all.d completely, but you're obviously free to use it all.d if you want to.
Yes, but it's obviously not useable at this point and when it does it will be easy to switch over to. AFAIK, the only issue with uppercase is case sensitivity, and as long as d does not modify case then I'm not worried about it. Just because something is frowned apon doesn't mean squat to me unless there is a good reason. I'll prefer readability over common useage. Essentially all emulates the package.d, and I like it because it's descriptive and easily maintainable... thats all I was after in the first place. Too bad package doesn't work properly ;/
Jul 18 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was after
 in the first place. Too bad package doesn't work properly ;/
Do you mean the package attribute or package.d? package.d should work just fine. I'm not aware of any outstanding bugs with it. The attribute is still broken though, I believe. - Jonathan M Davis
Jul 18 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was 
 after
 in the first place. Too bad package doesn't work properly ;/
Do you mean the package attribute or package.d? package.d should work just fine. I'm not aware of any outstanding bugs with it. The attribute is still broken though, I believe. - Jonathan M Davis
When I used package.d things didn't work out like they do using all. It may be due to bugs on my end(I had a few typos). Maybe I will try it again though(simple rename and remove .all).
Jul 18 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, July 18, 2013 23:53:53 JS wrote:
 On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was
 after
 in the first place. Too bad package doesn't work properly ;/
Do you mean the package attribute or package.d? package.d should work just fine. I'm not aware of any outstanding bugs with it. The attribute is still broken though, I believe. - Jonathan M Davis
When I used package.d things didn't work out like they do using all. It may be due to bugs on my end(I had a few typos). Maybe I will try it again though(simple rename and remove .all).
Well, what you were posting was wrong, and I believe that I pointed out why. A package.d file's module declaration needs to have the same name as the package. So, if you have abc/foo/package.d then package.d needs module abc.foo; for its module declaration. Then you import the package as if it were a module, so you get any public imports which were in it. But as I said before, this won't work for the top level, because the top level isn't a package. You need a sub-folder to have a package. - Jonathan m Davis
Jul 18 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 18 July 2013 at 23:14:39 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 23:53:53 JS wrote:
 On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis 
 wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it 
 because
 it's descriptive and easily maintainable... thats all I was
 after
 in the first place. Too bad package doesn't work properly ;/
Do you mean the package attribute or package.d? package.d should work just fine. I'm not aware of any outstanding bugs with it. The attribute is still broken though, I believe. - Jonathan M Davis
When I used package.d things didn't work out like they do using all. It may be due to bugs on my end(I had a few typos). Maybe I will try it again though(simple rename and remove .all).
Well, what you were posting was wrong, and I believe that I pointed out why. A package.d file's module declaration needs to have the same name as the package. So, if you have abc/foo/package.d then package.d needs module abc.foo; for its module declaration. Then you import the package as if it were a module, so you get any public imports which were in it. But as I said before, this won't work for the top level, because the top level isn't a package. You need a sub-folder to have a package.
Yes, that is one of the things I tried.. and I'm not working from the top level since that is the library container folder which contains all the actual libraries which then contain the packages. When I rename the all.d files to package and import the package I get two errors: Error 1 Error: can only import from a module, not from package JS Error 2 Error: module JS is in file 'JS.d' which cannot be read My hierarchy is /lib/JS/package.d module JS; public import .... and I import JS by using import JS; vs using all.d /lib/JS/All.d module JS.All; public import .... and I import JS by using import JS.All; otherwise everything is identical. .All works without issue. Note I reverted to 2.062 because 2.063.2 was causing weird errors in Visual D... so this might be the problem but I remember getting the same errors when I was trying 2.063.2(but possibly not)... In any case, I'll just stick with All for now, I think I like how explicit it is.
Jul 18 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, July 19, 2013 01:25:54 JS wrote:
 Note I reverted to 2.062 because 2.063.2 was causing weird errors
 in Visual D... so this might be the problem but I remember
 getting the same errors when I was trying 2.063.2(but possibly
 not)...
As I think that I said earlier (though maybe I forgot to), you have to have git master to use package.d. The feature hasn't been released yet. - Jonathan M Davis
Jul 18 2013
parent "JS" <js.mdnq gmail.com> writes:
On Friday, 19 July 2013 at 00:39:03 UTC, Jonathan M Davis wrote:
 On Friday, July 19, 2013 01:25:54 JS wrote:
 Note I reverted to 2.062 because 2.063.2 was causing weird 
 errors
 in Visual D... so this might be the problem but I remember
 getting the same errors when I was trying 2.063.2(but possibly
 not)...
As I think that I said earlier (though maybe I forgot to), you have to have git master to use package.d. The feature hasn't been released yet. - Jonathan M Davis
Ok, that explains it. I thought getting 2.063.2 would be good enough. I didn't want to have to compile anything so didn't bother looking at github. It would be nice if there was always a latest compiled version of master for download(or at least a nightly or weekly build)?
Jul 19 2013
prev sibling parent "JS" <js.mdnq gmail.com> writes:
One of the reasons I used Package.d was so I can get around an 
issue like 
https://github.com/D-Programming-Language/dmd/pull/2152 which I 
think I was running into.

Instead I think by renaming Package.d to All.d and import 
dir.All; seems to work ok. Obviously adding .All to everything is 
annoying but it won't be hard to write a parser to fix that once 
package gets working.
Jul 18 2013