Organization of modules in project D

Question

I come from Java backgrounds and the packaging problem is as follows:

I can have many files under the same package, say com.parobay.io . I can then distribute this as a library, and users will use it as follows:

 import com.parobay.io.Input; import com.parobay.io.Output; 

or

 import com.parobay.io.*; // to import everything 

That way I can have one module ( com.parobay.io ) and classes defined in several files.

So how do I achieve the same in D? Do I need to create the com\parobay\io directory and place two files named Input.d and Output.d or is there a smarter way?

In Java, the rules are very strict, so it’s hard to make a mistake. There are many possibilities in D. So, are there any conventions, such as one class for a file, or a file name equal to the class name?

Answer 1

You can do this basically the same as Java, although remember these elements:

• import foo.* does not work in D, but you can make a file called package.d in a directory that manually lists public import foo.Input; public import foo.Output; public import foo.Input; public import foo.Output; etc., which allows you to import the entire package.

• ALWAYS put the line module com.parobay.io.Input; or any other line at the top of any imported file. Do not expect it to work only based on the directory structure and file name. The directory structure is actually not strictly necessary, it is just an agreement to easily find the file. The module line at the top with the name is the authoritative thing that the compiler checks.

• D modules often have all lowercase names, but you can use uppercase letters if you want. I think it's useful to use a lowercase name, such as a class name, so you can call the io.input module and the Input class. The reason for this agreement is sometimes that when you switch from system to system, the file name is lost. But the developers are well aware of the case, so in practice, any of them should work.

• One class for each file will work fine, or you can put two closely related classes together in the same file (they will have access to each other private member if they are in the same file).

See this page for more information: http://dlang.org/module especially the search for the header "Package Module"

Answer 2

Do not use two separate files for the Input and Output classes. Instead, put both classes in the same file, parobay/io.d (corresponding to the parobay.io module).

This is definitely not a convention limiting itself to just one class per file. D are for grouping code related functions. When someone does import parobay.io; they expect to receive all parobay.io - classes, utility functions and everything else. It is similar to Java import com.parobay.io.*; .

If someone really wants to import certain parts of your module, they can use selective import:

 import parobay.io: Input; // Just the Input class of the parobay.io module. import parobay.io: Output; // Just the Output class. import parobay.io: Input, Output; // Just the Input and Output classes. 

There are a few additional notes about this.

• Package and module names are usually lowercase.
• This makes life easier for each user if the file path matches the full name of the module. For example, the module foo.bar.baz should be in the file foo/bar/baz.d
• In my experience, it is rare that a D-module will be named after a domain name. You can prefix your module names with com or org or net if you really want to, but this was not expected, as in Java.

Adam D. Ruppe's answer contains several comments regarding explicit module declarations and the visibility of class members. It is also worth reading the module and style pages of the official D site .

Answer 3

Community

D has three widespread alternatives.

• Write a module named all.d that includes all the modules from your package. (Literally "*" → "all"). After that, you simply do import com.paroboy.io.all;

• I see more and more that D developers are using _ for this. Therefore, for this purpose they write a module called _.d . Similar to # 1, you do import com.paroboy.io._;

• A relatively new addition to the D programming language is the package.d module, which can be used to import a package. More on this in the next DIP: http://wiki.dlang.org/DIP37 . If I remember well, DMD has supported it since version 2.04. (Documentation: http://dlang.org/module#PackageModule )

I myself use approach number 1, because it is obvious what is happening. Although # 2 and # 3 can confuse people reading the original D file, especially the third. A valid question that someone might ask is: "Why the hell am I importing a package? But import is only for modules! ??"

All that nothing prevents you from having a separate module for each class, I would not recommend it. D is truly a modular language, so take advantage of this. Group all your types in one module D. This is my advice, and this is "path D".

Note: There is a (big) semantic difference between the Java module and the D module, as you probably already noticed. I am primarily a Java programmer, so I know how confusing Java programmers can be when playing with D. Java classes in the same package, which often take advantage of package-level access. However, classes inside the same module behave like “friends” in C ++.

Speaking of Java modules , they should have shipped with Java 8 (real modules!), But have been delayed and hopefully will be included in Java 9.

UPDATE: We conclude, after chatting on FreeNode (IRC) with some members of the D-Programming-Language , that it is now really safe to use the package attribute. It behaves as specified in the specification.