www.digitalmars.com         C & C++   DMDScript  

D - Modules specification

reply "Juarez" <juarez mps.com.br> writes:
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 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
Dec 28 2001
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Juarez" <juarez mps.com.br> wrote in message
news:a0ikqh$h0q$1 digitaldaemon.com...

 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.
Dec 28 2001
parent reply "Juarez Rudsatz" <juarez correio.com> writes:
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

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 ?
Jan 07 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Juarez Rudsatz" <juarez correio.com> wrote in message
news:a1d0lg$1iep$1 digitaldaemon.com...


     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.


    private:
        int func1() { }
        ...
        int func200() { }

- or -

    private
    {
        int func1() { }
        ...
        int func200() { }
    }

This all is already in D.


 Is this reasonable ?

 import system, file, time;


Yes!
Jan 07 2002
parent reply "Juarez Rudsatz" <juarez correio.com> writes:
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 ?
Jan 07 2002
parent "Walter" <walter digitalmars.com> writes:
"Juarez Rudsatz" <juarez correio.com> wrote in message
news:a1dfl1$1rcu$1 digitaldaemon.com...

 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.
Jan 08 2002