What are modules for?

[Jonathan M Davis]

On Thursday 25 November 2010 16:05:42 rickned wrote:
> Modules, files, packages, compilation units...
> 
> I have a class that is designed to be derived from. Can I put it in
> a module (file) so other people can import the module (file) like a
> C-c++ header so they can derive from it? Is that the idomatic way
> to do that in D? I don't want to expose the method definitions,
> mind you. I understand deeply the C++ way of doing things like
> hiding implementation and interfaces etc. Can someone bring it all
> together for me in D? And note that the hiding part is not the gist
> of my question, but rather that I want to understand the D way but
> am probably trying to contrast it to the C++ way. I have TDPL
> (borrowed from the library, and it's a one without Andy's name on
> the cover), but I started reading it in the module chapter but
> found it rather confusing, if not lacking all the pertinent info.

A module is a file. If it is not a base package, then the directory that it is in 
is it's package. So, std.file, for instance, is going to be std/file.d where std 
is a directory in the base directory, and std is the package that the file module 
is in. packages relate directly to directories, and modules relate directly to 
files.

public: Anything has access to it. If it's a function, anything can call it. If 
it's a type, anything can use it (and construct it assuming that its 
constructors are public and it's not abstract). If it's a class, any class can 
derived from it.

package: Anything in the same package can access it, and only anything in the 
same package can access it. So, for instance, if std.file had a function with 
package level access, then anything in the std package (std.stdio, 
std.algorithm, etc.) could use it, but nothing outside of the std package could 
access it. So, for a class, any class in the same package can derive from it, 
but nothing outside of the package can derive from it.

protected: Derived classes have access to it and anything in the same module has 
access to it. Nothing outside of the module which is not derived from the class 
containing the protected member variable or function cannot access it.

private: Anything in the same module has access to it, but nothing outside of 
the module does.

Normally, the entire implementation goes in a single file, and that is the 
preferred way to do it. You don't separate a function's implementation/definition 
from its declaration. You can, create .di files which have function declarations 
leaving the definitions in a .d file ( http://www.digitalmars.com/d/2.0/dmd-
linux.html#interface_files ), but those are specific to dmd (as opposed to the D 
language), and they're not generally the way that it's done. It's really only 
for when you need to separate out the implementation from the interface. And I'm 
not sure that those work very well with templates, since you need the whole 
template definition when instantiating a template, and templates are typically 
very heavily used in D.

- Jonathan M Davis