www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are modules for?

reply rickned <nospam nospam.net> writes:
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.
Nov 25 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
rickned <nospam nospam.net> 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?

Yes. Any non-final public class in an imported module can be derived from.
 Is that the idomatic way to do that in D?

There is the option of using a .di file, if you want to hide implementation. .di files are normal D source files, with implementation stripped. Due to the compilation speed (I believe) and no requirement to hide implementation, most projects I've seen simply use .d files.
 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?

See above. .di files are basically what you'd expect to be the D equivalent of a .h file.
 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.

-- Simen
Nov 25 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 25 2010
parent Mafi <mafi example.org> writes:
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
Nov 26 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:
 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)

This is false. .di files are simply .d files with a different extension. Any compiler that supports the compilation of .d files will support .di files (granted, it may only look for .d files).
 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.

Template definitions are left in the .di file. -- Simen
Nov 26 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 00:44:03 Simen kjaeraas wrote:
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 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)

This is false. .di files are simply .d files with a different extension. Any compiler that supports the compilation of .d files will support .di files (granted, it may only look for .d files).

I believe that Walter has stated that .di files are a dmd-specific thing and are not actually a part of the D language. That doesn't stop other compilers from supporting them, but they are effectively a dmd-specific language extension. The language itself specifies .d files as being d source files but says nothing about .di files. - Jonathan M Davis
Nov 26 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Friday 26 November 2010 00:44:03 Simen kjaeraas wrote:
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 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  

 to the D
 language)

This is false. .di files are simply .d files with a different extension. Any compiler that supports the compilation of .d files will support .di files (granted, it may only look for .d files).

I believe that Walter has stated that .di files are a dmd-specific thing and are not actually a part of the D language. That doesn't stop other compilers from supporting them, but they are effectively a dmd-specific language extension. The language itself specifies .d files as being d source files but says nothing about .di files.

They are not a defined part of the D language because they don't need to. They are simply D source files. The dmd-specific part of it is that dmd supports generating .di files from .d files. -- Simen
Nov 26 2010