Thoughts about modules

Andrei Khropov andkhropov at nospam_mtu-net.ru
Tue Jun 27 08:18:31 PDT 2006


Hi all,

I just want to share some thoughts about modules and their import.

When we want to import a module we should decide on 2 things:

1) do we want to import names from the module to the local namespace?

2) do we want this import to be propagated to the files that include the module 
we import in?

In D the second question can be answered "no" by adding "private" modifier to
the import statement, but the first question is always answered "Yes".
I think it's not a good idea. My opinion is that notions 
"I want to use a module" and "I want names in the module to be imported in the
current scope" should be separated.

Like in C++ we have (of course C++ don't have true modules but I want to show
an example):
---------------------------
#include <iostream>		// "Import" a module

using namespace std;		// import declarations in "std" in the current scope
---------------------------

So I would like to see a possibility to answer "no" to the first question and
use fully qualified names if I want to avoid name conflicts.

So maybe default behavior of "import" should be changed (and later symbols
could be imported to the current scope by some kind of "alias" statement) or an
alternative declaration to import modules ("using" ?) could be added to mean
"use declarations from the module but keep them in that module's namespace".

--------------------------------------------------------------------------------

Another thing I would like (maybe a beyond 1.0 feature) is that compiled
modules should contain both the module interface and implementation so we don't
need to have separate "d/di" interface files and "lib" with implementation.

When compiler finds an "import" declaration it finds a module (or maybe whole
package of modules in one file), imports its symbol table and also passes
module name to the linker so we don't have to pass module name as the linker's
parameter explicitly as it has already been declared in the source files.
 

-- 
AKhropov



More information about the Digitalmars-d mailing list