D people :
I have thinking in some thinks viewed here. Consider this issues:
o Implementation protection and hiding.
Supose I am writing a module containing two ou mais functions, just for
example. One of that, is a simple implementation needed for another. When I
do "import" in another module, the both functions will be available. I could
not see how can be this hided.
o D module file type.
D module file are simple text file, ascii or wchar. There are no way of
discover if a file is D without parsing it.
o Obejct file name.
Is usual in C when compiling a file.c give for object the name file.o or
similar. But supose a architecture dependent module and two or more
architetures. For organizing your work could be good separate the
implementation in different files but doing "import" in another module for
the same module name. Supose for example sockets in win32 and *nix, In
architecture independent code you will want impor sockets and not winsock
_or_ sockets.
The proposal is formalizing the module structure. The module sintax could
be some like the following example. The form and the tokens could change.
This is a simple idea.
winsock.d
--------------------------
module socket {
/* Simple module with examples */
import system, file, time;
public
int func1() {
return func2()
}
private
int func2(){
return 2;
}
public
int func3(){
return 3;
}
}
___________________________
A d v a n t a g e s :
o The files have one or more hided place for implementation stuff. None
declaration in this sections will expand.
o The object file could be generated, by default, in base of the module name
and not by file name. Then two files could have the diferent implementation
of same module. This could help for code understanding.
o The file could have "module" as first word for identifying purposes. Then
applications could interpret easily and take decisions smarter.
o Apparently this not affect the distinc fases of compilation.
o In embebbed file, like html, you will know when c code start and end.
P r o b l e m s :
o More tokens: "module" and more digitation.
o Requiring "module" as first word is " #$%!#¨#¨", but is better than
shebang # or XML header <?XML bla bla bla .
o Permiting same module in two files will do a duplication of code and
effort for maintaining. But this is not a rule, is a few cases. Anyway the
will be duplicated without this feature and worst, will implicate in imports
by anothers modules.
Comments, Sugestions, Negatives ?
Sorry for bad English.
Juarez Rudsatz

o Implementation protection and hiding.
Supose I am writing a module containing two ou mais functions, just for
example. One of that, is a simple implementation needed for another. When

I

do "import" in another module, the both functions will be available. I

could

not see how can be this hided.

You can use the "private" attribute:
private void util(); // not visible from other modules
void action(); // visible from other modules
The same works for variables and everything else.

o D module file type.
D module file are simple text file, ascii or wchar. There are no way of
discover if a file is D without parsing it.

I think Walter will add some "compiled module" file sooner or
later. Or maybe an interface file, that, in conjunction with
compiled code in OBJ-file, gives the full module without revealing
its source.

o Obejct file name.
Is usual in C when compiling a file.c give for object the name file.o or
similar. But supose a architecture dependent module and two or more
architetures. For organizing your work could be good separate the
implementation in different files but doing "import" in another module for
the same module name. Supose for example sockets in win32 and *nix, In
architecture independent code you will want impor sockets and not winsock
_or_ sockets.

Imports can be nested. If A imports B, and B imports C, then A
imports C. In your case with sockets, Windows version of module
"sockets" would import "winsock", while on *nix it woudln't. So
you just import "sockets" regardless of platform you use, and
then can be sure that you get AT LEAST all functionality common
to both programs, and probably also all WSA... functions on
Windows.

D people :
I am not convinced yet. :-)
See the following hypothetical code :
module socket {
public :
int func1() { return func2() }
private :
int func2(){ return 2; }
...
int func200() { return 200; }
}
And here the same points :
o Implementation protection and hiding.
Supose I am writing a module containing two ou mais functions, just for
example. One of that, is a simple implementation needed for another. When I
do "import" in another module, the both functions will be available. I could
put a private before each declaration like this:
private int func200() { .. }
But supose 200 or more variables, function, constants, structs, etc. If
exists a hidden place, I could save typing, prevent mistakes and make code
clear. Maybe someone could show me the problems with this construction.
o D module file type.
D module file are simple text file, ascii or wchar. There are no way of
discover if a file is D code without parsing it.
When I wrote this, I not thinking in header files for programers reading and
understanding. I think in how anothers program will detect a D source file.
Pdf documents start with a "%PDF" string. shell scripts start with
"#!/bin/someshell". There are another documents with fixed identificators.
With Module as first word the D files could be automatic detected
independently of file name or extension. Is how mime magic does in Linux or
Shell interprets scripts.
This is not so important. But
o More things :
Is this reasonable ?
import system, file, time;
and this :
void doSomething() {
import stdio;
int local;
...
}
How local declaration, local import could have local scope ? There are
several problems ? Or this is simply sintatic sugar ?
What you think about this ?
Comments, Sugestions, Negatives ?

example. One of that, is a simple implementation needed for another. When

I

do "import" in another module, the both functions will be available. I

could

put a private before each declaration like this:
private int func200() { .. }
But supose 200 or more variables, function, constants, structs, etc. If
exists a hidden place, I could save typing, prevent mistakes and make code
clear. Maybe someone could show me the problems with this construction.

D People:
All problems in this thread appear to have already included at least one
solution in D spec. My messages fall into a support question. IMHO, the
language is reaching a very mature state.
There are just one little thing :
void doSomething() {
import stdio; /* This have local scope ? */
int local;
...
}
private {
import stdlib; /* This will expand for another module ? */
import stdio; /* This will conflict with doSomething -> stdio ? */
...
}
The question is : can import have local scope ?

D People:
All problems in this thread appear to have already included at least

one

solution in D spec. My messages fall into a support question. IMHO, the
language is reaching a very mature state.
There are just one little thing :
void doSomething() {
import stdio; /* This have local scope ? */
int local;
...
}
private {
import stdlib; /* This will expand for another module ? */
import stdio; /* This will conflict with doSomething -> stdio ? */
...
}
The question is : can import have local scope ?

Yes, they can, within that local scope. You can also import the same module
as many times as you want in multiple scopes.