How about an attibute to the 'module' statement. E.g. public:

file mypackage/mymod1.d:
public module mypackage.mymod1;

file mypackage/mymod2.d:
module mypackage.mymod2;


the import with a star, does now an import of all modules in the package, which have a 'public' module statement.

file main.d:
import mypackage.*; // imports mypackage.mymod

On Sat, 2006-10-28 at 12:39 +0200, Frank Benoit (keinfarbton) wrote:
> the import with a star, does now an import of all modules in the package, which have a 'public' module statement.

I'd say that importing with an asterisk is a bad practice, because it
hints, that the user could write something like this:
	import package.*ule
Or even:
	import pack*.*ul*.*

So, I must still insist on using just the package name and not the Java style asterisk.

Mart

Mart Roosmaa wrote:
> Hello everybody,
> 
> I am quite new to D and when learning how the packages and modules
> worked, it seemed strange to me that if one wanted to import whole
> packages one would have to create a module (for example a module called
> "All") and do public imports of every other module in the package.
> 
> While this approach works, it's quite painful to keep that module up to
> date, as people tend to forget to update the central module doing the
> public imports.
> 
> Now, I propose to extend the import declaration so that if only a
> package is given, it imports all modules in that package.
> For example "import std.c;" would import std.c.fenv, std.c.math,
> std.c.process, std.c.stdargs, etc modules.
> 
> This approach would keep the code a bit easier to maintain as one
> wouldn't have to update the public imports module all the time.
> 
> What do you think? Could it be implemented in DMD?

Even though Java allows this, it is generally regarded as poor practice. I have often seen coding standards that forbid it, requiring each class used to be imported explicitly. Explicit import of each class greatly reduces the chance of naming collisions, but also serves as a sort of documentation on which classes from a package are used in any given source file. Perhaps the most well-known examples of this are the Apache projects. If you look through the source to any Apache project, you won't find the use of .* imports.

If this were to be implemented in D, I would prefer to see the java syntax of mypackage.*, or something similar. Otherwise, it isn't immediately obvious by reading the code if an entire package is being imported or not. Consider this:

import foo.bar.blue;

Under your proposal, is blue a module or a package? It is assumed that users of a library would know the difference, since they are using the library anyway. But when it comes to code reviews, library examples, or any other situation where people not intimate with the package structure need to see the code, it adds to the learning curve and could cause confusion. Using the Java syntax, import foo.bar.*, makes it clear that all modules in bar are being imported.

I wouldn't use it myself, but I would only object to such a feature if implemented as you propose. Having an explicit syntax for package import, such as .*, would be okay. Though I'm of the opinion that use of it would reduce code quality.

BLS wrote:

> I think you mean: Can't Mr. Compiler handle this task....?!

No. I wanted to know, what justification the OP gives for the existence of import statements.

If he would have given "avoiding name collisions" then he would have been in the immediate need to show, that name collisions in packages cannot happen, which seems to be an impossible mission.

There might be other arguments, but all would be broken, as soon as one starts to allow for pruning the hierarchy.

The ultimate question after such a start would be:

    Why do I have to write "import *;"?