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.

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

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

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.
> 
> 
> 

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.

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.

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.