What are modules for?

[Mafi]

Am 26.11.2010 02:38, schrieb 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:[...]
>
> package: [...]
>
> protected:[...]
>
> private: [...]
>
> [...]
>
> - Jonathan M Davis

There's also 'export'. It marks the definition as visible from outside 
the excutable/dll (and I think '.so' too). Of course it's also 
accessible inside the executable.
When using C dlls you should mark it's signatures as 'extern(c) export'.

Mafi