What's the "best practice" surrounding modules and packages?

I want to have a library of reusable code that I can import into an app-specific .d file with a single statement.  This library is composed of dozens of classes, each in its own file/module.

In C++ I'd create a single global.h file that includes the .h files for all library classes.  In this way, the app-specific code can include the entire library with a single #include statement.

In D I *think* I can do the same thing: just create a global.d file that imports all the .d files of the library.  Thus the app-specific code just imports the library.global module, and it gets the whole thing.

Is this the way it's supposed to be done?

I'd prefer some kind of wildcard import, like:

#
# import library.*;
#

But that doesn't appear to work.

What have people been doing to organize and separate their reusable and app-specific code?

-david

For libraries thats what ive done, create module project.api; which contains all nessecary imports.

For most other imports its usually necessary to import them at the class level to avoid forward reference problems, which for large projects can be a show stopper ( DWT I know has struggled with it ).

Chuck

In article <cc5ipd$22jv$1@digitaldaemon.com>, news.digitalmars.com says...
>
>What's the "best practice" surrounding modules and packages?
>
>I want to have a library of reusable code that I can import into an app-specific .d file with a single statement.  This library is composed of dozens of classes, each in its own file/module.
>
>In C++ I'd create a single global.h file that includes the .h files for all library classes.  In this way, the app-specific code can include the entire library with a single #include statement.
>
>In D I *think* I can do the same thing: just create a global.d file that imports all the .d files of the library.  Thus the app-specific code just imports the library.global module, and it gets the whole thing.
>
>Is this the way it's supposed to be done?
>
>I'd prefer some kind of wildcard import, like:
>
>#
># import library.*;
>#
>
>But that doesn't appear to work.
>
>What have people been doing to organize and separate their reusable and app-specific code?
>
>-david
>
>

news.digitalmars.com wrote:

> What's the "best practice" surrounding modules and packages?
> 
> I want to have a library of reusable code that I can import into an
> app-specific .d file with a single statement.  This library is composed of
> dozens of classes, each in its own file/module.
> 
> In D I *think* I can ... just create a global.d file that
> imports all the .d files of the library.  Thus the app-specific code just
> imports the library.global module, and it gets the whole thing.
> 
> Is this the way it's supposed to be done?
> 
> I'd prefer some kind of wildcard import, like:
> 
> #
> # import library.*;
> #
> 
> But that doesn't appear to work.
> 
> What have people been doing to organize and separate their reusable and
> app-specific code?

I just make a module of the same name as the package.  It's a tad awkward to say

    import libfork.libfork;

But I think the meaning is clear enough.  I've seen 'all.d' used as well.  It'd be nice to have an explicit convention for this sort of thing, but I'm happy as long as it says what it is. :)

 -- andy

In article <cc6qas$112n$1@digitaldaemon.com>, Andy Friesen says...

>I just make a module of the same name as the package.  It's a tad awkward to say
>
>     import libfork.libfork;
>
>But I think the meaning is clear enough.  I've seen 'all.d' used as well.

Yeah, that's what I do too. Hence etc.bigint.bigint, etc.crypto.crypto and etc.unicode.unicode. (The latter two aren't actually there yet).


>It'd be nice to have an explicit convention for this sort of thing, but I'm happy as long as it says what it is. :)

Well, I borrowed the idea from std.windows.windows and std.linux.linux. I guess if Phobos can do it, that gotta at least count towards a convention.

Arcane Jill

In article <cc76jk$1i2p$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cc6qas$112n$1@digitaldaemon.com>, Andy Friesen says...
>
>>I just make a module of the same name as the package.  It's a tad awkward to say
>>
>>     import libfork.libfork;
>>
>>But I think the meaning is clear enough.  I've seen 'all.d' used as well.
>
> etc.bigint.bigint
> etc.crypto.crypto
> etc.unicode.unicode
> std.windows.windows
> std.linux.linux

I don't like it, it's not really descriptive.
both all.d and api.d look better to me.

DUI has "All.d" but it will change to "all.d"

but this is a minor issue.

Ant

Ant wrote:
> In article <cc76jk$1i2p$1@digitaldaemon.com>, Arcane Jill says...
> 
>>In article <cc6qas$112n$1@digitaldaemon.com>, Andy Friesen says...
>>
>>
>>>I just make a module of the same name as the package.  It's a tad awkward to say
>>>
>>>    import libfork.libfork;
>>>
>>>But I think the meaning is clear enough.  I've seen 'all.d' used as well.
>>
>>etc.bigint.bigint
>>etc.crypto.crypto etc.unicode.unicode
>>std.windows.windows
>>std.linux.linux
> 
> 
> I don't like it, it's not really descriptive.
> both all.d and api.d look better to me.
> 
> DUI has "All.d" but it will change to "all.d"
> 
> but this is a minor issue.
> 
> Ant
> 
> 
<Java>
Walter, can we have * added to the valid identifier characters? ;-)
</Java>

Sam

In article <ccaoqp$fli$1@digitaldaemon.com>, Sam McCall says...

><Java>
>Walter, can we have * added to the valid identifier characters? ;-)
></Java>

Is there any reason why the import statement can't be made to allow:

#    import abc.def.*;

meaning, import all .d files in directory .../abc/def?
(just like Java does)

Arcane Jill

I was thinking the same thing, but then again maybe you wouldn't want to include all of the modules. What Java does mostly with the classes that Sun created are built in to the VM so that when you compile the code, you aren't actually including any of those classes. Just opcodes of the classes so that the VM can tell what class you were using. This allows you to use the '*' without having bloat. D would only include a module once in the program but would include/import ALL of the modules if you use them or not.

If it can tell if you used a module or not then I would agree that it would be useful.

> Is there any reason why the import statement can't be made to allow:
> 
> #    import abc.def.*;
> 
> meaning, import all .d files in directory .../abc/def?
> (just like Java does)
> 
> Arcane Jill

On Mon, 5 Jul 2004 20:40:37 +0000 (UTC), Arcane Jill
<Arcane_member@pathlink.com> wrote:

>Is there any reason why the import statement can't be made to allow:
>
>#    import abc.def.*;
>
>meaning, import all .d files in directory .../abc/def?
>(just like Java does)

Actually, I really dislike Java's wildcard imports. It makes it non-obvious which sub-packages are being imported. This can be a pain when using a tool like grep to search for source files which import a particular package or module.

As a matter of style, when I'm writing Java code, I always include a separate import statement for each distinct package/module that I'll be using. Not only does this provide for clearer, more precise code, it also prevents enormous amounts of runtime bloat that would otherwise result from loading classes that won't be used during program execution. (I imagine that a similar amount of bloat is avoided in D by getting rid of the wildcard imports.)

That's my 2c, anyhow.

--Benji Smith

In article <g6sje0po6iulbho0t8j5fab8gga4nr1kkb@4ax.com>, Benji Smith says...
>
>On Mon, 5 Jul 2004 20:40:37 +0000 (UTC), Arcane Jill
><Arcane_member@pathlink.com> wrote:
>
>>Is there any reason why the import statement can't be made to allow:
>>
>>#    import abc.def.*;
>>
>>meaning, import all .d files in directory .../abc/def?
>>(just like Java does)
>
>As a matter of style, when I'm writing Java code, I always include a separate import statement for each distinct package/module that I'll be using.

Understood, and actually I agree with you. However, that's not really what we're talking about. Suppose I write a "distinct package" comprising two hundred individual files. It would makes sense for me to provide a single importable module which imports all the others. The original question on this thread was "What should that module be called"?

Phobos (and now Deimos) uses:

#    import abc.def.def;

Others prefer:

#    import abc.def.all;

Of course, what we'd ALL prefer is:

#    import abc.def;

But D doesn't allow that (module and package with same name). And so, as a kind of "second choice", I ventured that:

#    import abc.def.*;

might be an acceptable alternative. I guess what we really need here is a proclaimation in the style-guide. I'm not hung up on ANY particular convention, but I do want "what people expect" to "just work", and what people expect is entirely dependent on consistency across multiple projects.

Arcane Jill