www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D default directory module?

reply AJG <AJG_member pathlink.com> writes:
Hi there.

I have a question for the module gurus. Let's say I have a module named
conceptually Foo. If Foo is simple enough, I could live with having just Foo.d
and placing it pretty much wherever. Thus, a simple "import Foo;" would do.

However, my Foo is growing more complex, and it's now several files. Thus, I
want it to live in its own folder, called (surprise!) Foo. Is there any way to
do this and still be able to do "import Foo;" ?

I can't find a way, and my current hack is to have Foo.d inside folder Foo,
which results in the ugly "import Foo.Foo;". I suspect this is what's going on
with "linux.linux."

Are there any solutions to this problem right now? Or should I make a suggestion
for something like "index.d" a la Apache, meaning index.d is the "default"
module to import in a folder if no _specific_ one is called for.

Thinking out loud, perhaps instead of "index.d" it could be Folder_Name.d, or
something like that.

Thanks,
--AJG. 
Aug 07 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 8 Aug 2005 02:38:06 +0000 (UTC), AJG <AJG_member pathlink.com>  
wrote:
 Hi there.

 I have a question for the module gurus. Let's say I have a module named
 conceptually Foo. If Foo is simple enough, I could live with having just  
 Foo.d
 and placing it pretty much wherever. Thus, a simple "import Foo;" would  
 do.

 However, my Foo is growing more complex, and it's now several files.  
 Thus, I
 want it to live in its own folder, called (surprise!) Foo. Is there any  
 way to
 do this and still be able to do "import Foo;" ?

 I can't find a way, and my current hack is to have Foo.d inside folder  
 Foo,
 which results in the ugly "import Foo.Foo;". I suspect this is what's  
 going on
 with "linux.linux."

 Are there any solutions to this problem right now? Or should I make a  
 suggestion
 for something like "index.d" a la Apache, meaning index.d is the  
 "default"
 module to import in a folder if no _specific_ one is called for.

 Thinking out loud, perhaps instead of "index.d" it could be  
 Folder_Name.d, or
 something like that.
Or "import <module>.all.d;". Some sort of convention is probably the solution which we will end up with. This has come up before, nothing was done then... D takes a more explicit stance than say Java in that you cannot "import module.*;" Regan
Aug 07 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,

 Are there any solutions to this problem right now? Or should I make a  
 suggestion
 for something like "index.d" a la Apache, meaning index.d is the  
 "default"
 module to import in a folder if no _specific_ one is called for.

 Thinking out loud, perhaps instead of "index.d" it could be  
 Folder_Name.d, or
 something like that.
Or "import <module>.all.d;". Some sort of convention is probably the solution which we will end up with. This has come up before, nothing was done then... D takes a more explicit stance than say Java in that you cannot "import module.*;"
I think it would be a good idea to make official this convention (whatever it ends up being), and then make it the directory default. That way instead of having to use: import <module>.all; You could just do import <module>; Which would work just like if module were a single file. Cheers, --AJG.
Aug 08 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 8 Aug 2005 02:38:06 +0000 (UTC), AJG wrote:

 Hi there.
 
 I have a question for the module gurus. Let's say I have a module named
 conceptually Foo. If Foo is simple enough, I could live with having just Foo.d
 and placing it pretty much wherever. Thus, a simple "import Foo;" would do.
 
 However, my Foo is growing more complex, and it's now several files. Thus, I
 want it to live in its own folder, called (surprise!) Foo. Is there any way to
 do this and still be able to do "import Foo;" ?
 
 I can't find a way, and my current hack is to have Foo.d inside folder Foo,
 which results in the ugly "import Foo.Foo;". I suspect this is what's going on
 with "linux.linux."
 
 Are there any solutions to this problem right now? Or should I make a
suggestion
 for something like "index.d" a la Apache, meaning index.d is the "default"
 module to import in a folder if no _specific_ one is called for.
 
 Thinking out loud, perhaps instead of "index.d" it could be Folder_Name.d, or
 something like that.
 
This technique might be of some use to you. // ------------ FILE: foo\foo.d --------------- module foo.foo; // This is a public list of the files that make up the // 'conceptual' module "foo". import foo.foo_1; import foo.foo_2; // ------------ FILE: foo\foo_1.d --------------- module foo.foo_1; // This is a file in the "conceptual" foo module int func1() { return 1; } // ------------ FILE: foo\foo_2.d --------------- module foo.foo_2; // This is another file in the "conceptual" foo module int func2() { return 2; } // ------------ FILE: test.d --------------- import foo.foo; // Import the list of "foo" files. import std.stdio; void main() { writefln("1 = %s", foo.foo.func1()); // use the "conceptual" mod name. writefln("2 = %s", foo.foo.func2()); } I then compile this with ... build test Or if you like the DMD method ... dmd -op foo\foo_1.d foo\foo_2.d foo\foo.d test.d -oftest.exe -- Derek Melbourne, Australia 8/08/2005 1:23:49 PM
Aug 07 2005
parent AJG <AJG_member pathlink.com> writes:
Hi Derek,

First of all I should really take the time to thank you for Build (it's yours,
right?). I find it simply _invaluable_ when it comes to developing in D. In
fact, that's the behaviour I was expecting from the language itself.

I was sorely dissapointed with DMD when it wouldn't automagically find modules,
but was later very pleased to see Build do it instead. Have you suggested to
Walter making Build part of the language/compiler?

This technique might be of some use to you. 
<snip>
import foo.foo;
Yeah, this is what I'm trying to avoid (just like "linux.linux"). Ideally, I could just do "import foo;" and then that would call a "default" module in the directory. This default module could be made standard, named foo.d, or all.d, or default.d, or index.d, or something like that. The other option suggested is to put Foo.d one directory higher than the rest, but then this breaks self-containment, and is kinda hack-ish. Some more praise for Build:
 build test
Simply beautiful.
Or if you like the DMD method  ...
dmd -op foo\foo_1.d foo\foo_2.d foo\foo.d test.d -oftest.exe
ICK! Cheers, --AJG.
Aug 08 2005
prev sibling parent reply John Demme <me teqdruid.com> writes:
If you'd rather not change your import do the following:
---foo_files/foo1.d----
//Code here
---foo_files/foo2.d----
//More code here
---foo.d---------------
public import foo_files.foo1;
public import foo_files.foo2;
---test.d--------------
private import foo;
//Use foo now
-----------------------

I'd be nice to have some automatic way to do it, but D's rather strict
about not doing much implicitly- which probably isn't a bad thing.

-John Demme

On Mon, 2005-08-08 at 02:38 +0000, AJG wrote:
 Hi there.
 
 I have a question for the module gurus. Let's say I have a module named
 conceptually Foo. If Foo is simple enough, I could live with having just Foo.d
 and placing it pretty much wherever. Thus, a simple "import Foo;" would do.
 
 However, my Foo is growing more complex, and it's now several files. Thus, I
 want it to live in its own folder, called (surprise!) Foo. Is there any way to
 do this and still be able to do "import Foo;" ?
 
 I can't find a way, and my current hack is to have Foo.d inside folder Foo,
 which results in the ugly "import Foo.Foo;". I suspect this is what's going on
 with "linux.linux."
 
 Are there any solutions to this problem right now? Or should I make a
suggestion
 for something like "index.d" a la Apache, meaning index.d is the "default"
 module to import in a folder if no _specific_ one is called for.
 
 Thinking out loud, perhaps instead of "index.d" it could be Folder_Name.d, or
 something like that.
 
 Thanks,
 --AJG. 
 
 
 
Aug 08 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,

Thanks for the help.

If you'd rather not change your import do the following:
---foo_files/foo1.d----
//Code here
---foo_files/foo2.d----
//More code here
---foo.d---------------
public import foo_files.foo1;
public import foo_files.foo2;
---test.d--------------
private import foo;
//Use foo now
-----------------------
Yeah, I thought about this, but it breaks the directory structure, which is really not an option. If a complex module is not self-contained, then that's just no good.
I'd be nice to have some automatic way to do it, but D's rather strict
about not doing much implicitly- which probably isn't a bad thing.
I like D's import concept, to get away from the ultra-literal #include's. However, not doing much implicitly is unfortunate in certain situations. It'd be nice to have something like Java's: import Foo.*. Or perhaps a default directory module (index.d/Foo.d/all.d). I think I'll suggest this soon. Cheers, --AJG.
Aug 08 2005