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 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
next sibling parent reply "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
parent reply 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
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  


 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.


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
prev sibling 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