What exactly module in D means?
I've been reading the newsgroup for a while, and it seems that one of
the reason folks like D is because it supports module.
My question is: what does module mean?
A quick google pointed my this page: http://dlang.org/module.html.
Still cannot understand it, though :)
How does it differ from the old C's #include?
For example, consider the hello world in C.
#include
int main(void){
printf("%s\n", "Hello world...");
return 0;
}
The C preprocessor while replace the line "#include " with the
content of stdio.h itself.
While in D:
import std.stdio;
void main(){
writeln("Hello world...");
}
Does that mean the compiler take the "definition" of writeln itself from
stdio.d and paste it into my program? Pardon my ignorance, because I'm
not versed in compiler theory.
Re: What exactly module in D means?
No, import is different from include. It does not stupidly copy and paste its content but tells the compiler to take the module into account for name resolution. The result may seem similar, but is much more efficient. A D module is also a unit of encapsulation (a private declaration in a module is only accessible from this module, and not from another one importing it).
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 17:08:01 UTC, Olivier Pisano wrote:
No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.
In fact, try to write the following C code:
int main() {
#include
[whatever else you want]
}
and look at those lovely error messages from the compiler :P
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 16:35:31 UTC, Andre Tampubolon wrote:
I've been reading the newsgroup for a while, and it seems that
one of the reason folks like D is because it supports module.
My question is: what does module mean?
A quick google pointed my this page:
http://dlang.org/module.html.
Still cannot understand it, though :)
How does it differ from the old C's #include?
For example, consider the hello world in C.
#include
int main(void){
printf("%s\n", "Hello world...");
return 0;
}
The C preprocessor while replace the line "#include "
with the content of stdio.h itself.
While in D:
import std.stdio;
void main(){
writeln("Hello world...");
}
Does that mean the compiler take the "definition" of writeln
itself from stdio.d and paste it into my program? Pardon my
ignorance, because I'm not versed in compiler theory.
You might find the clang docs on C++ modules worthwhile, though
they do it somewhat differently from D:
http://clang.llvm.org/docs/Modules.html
An #include simply copies and pastes the entire contents of the
C/C++ header into your source, which can happen over and over
again in a large project with no include guards, while modules
are a more sophisticated way of separating code.
Re: What exactly module in D means?
On Sat, Jul 5, 2014 at 6:35 PM, Andre Tampubolon via Digitalmars-d-learn wrote: > I've been reading the newsgroup for a while, and it seems that one of the > reason folks like D is because it supports module. > > My question is: what does module mean? > A quick google pointed my this page: http://dlang.org/module.html. > Still cannot understand it, though :) > > How does it differ from the old C's #include? Well, module are 'more first-class' in D than in C. By this, I mean that they have an identity: a name, members, symbols. You can see them as a enormous struct/class. You can use introspection to obtain the symbols defined in a module, query their types, etc. Heck, in some cases, module names can even by used as arguments for templates. As others said, a D module is a unit of encapsulation: inside a module, functions, structs and classes can freely call one other and access their internal fields. Outside the module, only what's not private is visible. Thus, you can create complex, interdependent structures inside your module, but export only some parts for public access. This way, you control a module 'interface', its external frontier. Importing a module in D means the public symbols defined in the module become accessible in the importer. There is no need to import all visible symbols in your current scope: you can restrict your import to only one or two symbols, rename them, etc. That's much more powerful than C when it comes to name clashes. Different 'downstream' modules can import the same 'upstream' module, and choose to import different symbols. No need to do a big 'import everything in the current scope'. symbols names are also defined on a per-module basis: two different modules can have members with a similar name, without clash: just prefix the names with the module name to differentiate them (or rename one while importing). Also, `import foo;` is a statement, you can put it everywhere a statement is legit. That's a recent addition (ie, 1-2 year?), that Andrei likes to call 'Turtles all the way down' and is quickly becoming a D idiom: import a symbol near its use place: inside a function, a method, even inside an if branch: that avoid scope pollution and nicely documents where a symbol is necessary.
