www.digitalmars.com         C & C++   DMDScript  

D - D Modules

reply Cameron Zemek <grom_3 optusnet.com.au> writes:
Sorry to repeat this question, but I still have not got an answer and still
confused even after re-reading the documentation on modules and writing some
sample code.

What are the differences between modules and Java packages?

For example, say I have the package hello with the classes HelloWorld,
CommandLine, and InvalidCommandLineArgument. In Java I would put them in the
following structure:

|- hello/
|---- HelloWorld.java
|---- CommandLine.java
|---- InvalidCommandLineArgument.java

With each file having "package hello;" at the top of the file.

With modules it seems each file is in seperate module. Eg. "module
hello.HelloWorld" and then each module in the package must import any other
modules it uses from the same package. In Java classes in the same package
can use other classes without importing. Am I missing something?
Feb 25 2004
next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Cameron Zemek wrote:

 Sorry to repeat this question, but I still have not got an answer and still
 confused even after re-reading the documentation on modules and writing some
 sample code.
 
 What are the differences between modules and Java packages?
 
 For example, say I have the package hello with the classes HelloWorld,
 CommandLine, and InvalidCommandLineArgument. In Java I would put them in the
 following structure:
 
 |- hello/
 |---- HelloWorld.java
 |---- CommandLine.java
 |---- InvalidCommandLineArgument.java
 
 With each file having "package hello;" at the top of the file.
 
 With modules it seems each file is in seperate module. Eg. "module
 hello.HelloWorld" and then each module in the package must import any other
 modules it uses from the same package. In Java classes in the same package
 can use other classes without importing. Am I missing something?

Not an expert here, but I don't think so. In Java everything within the same package can 'see' everything else in the package, while with D packages, anything in a module in that package can only see other modules if they are explicitly imported. Hopefully someone will correct me if I'm wrong. Cheers, Sigbjørn Lund Olsen
Feb 26 2004
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Cameron Zemek wrote:

 Sorry to repeat this question, but I still have not got an answer and still
 confused even after re-reading the documentation on modules and writing some
 sample code.
 
 What are the differences between modules and Java packages?

A module corresponds to a single source code file, rather than a whole folder. Imports are at the module level, rather than at the class level. Really, a module in D corresponds to a public class in Java, rather than to a package. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Feb 26 2004
prev sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Cameron Zemek" <grom_3 optusnet.com.au> wrote in message
news:c1k3h4$1tp3$1 digitaldaemon.com...
| Sorry to repeat this question, but I still have not got an answer and still
| confused even after re-reading the documentation on modules and writing some
| sample code.
|
| What are the differences between modules and Java packages?
|
| For example, say I have the package hello with the classes HelloWorld,
| CommandLine, and InvalidCommandLineArgument. In Java I would put them in the
| following structure:
|
| |- hello/
| |---- HelloWorld.java
| |---- CommandLine.java
| |---- InvalidCommandLineArgument.java
|
| With each file having "package hello;" at the top of the file.
|
| With modules it seems each file is in seperate module. Eg. "module
| hello.HelloWorld" and then each module in the package must import any other
| modules it uses from the same package. In Java classes in the same package
| can use other classes without importing. Am I missing something?


From the doc: "Modules have a one-to-one correspondence with source files."
So I think of modules as source files. You can group modules together
into directories and put "." as a standard directory separator.
Like in C/C++, a source file [module] can learn about another source file
[module] by using #include [import].
So the grouping and syntax is similar to Java but the semantics is
perhaps closer to C/C++.

One difference between #include and import, though, is that #include
makes the included file behave exactly the same as if it was typed in
the file - which has impact on name lookup - and import only adds the
file to a list of files to look in if the given name isn't found in
the original file.

-Ben
Feb 26 2004
parent reply "Matthias Spycher" <matthias coware.com> writes:
What do you think of the following extension:

File m.d contains the module declaration

module m : a, b, c;
...

where the semantics are:

a.d, b.d and c.d exist in the same directory as m.d and do not contain any
public import statements.

Thus module m consists of the unit:

module m;
#include a.d
#include b.d
#include c.d
...

if we used a C preprocessor to combine the files into a single module.

I for one would like to see the notion of a module expanded to cover
multiple files. Comparing to my Java packages, the corresponding D file
would otherwise be huge.

Matthias


"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c1krl2$30f$1 digitaldaemon.com...
 "Cameron Zemek" <grom_3 optusnet.com.au> wrote in message
 news:c1k3h4$1tp3$1 digitaldaemon.com...
 | Sorry to repeat this question, but I still have not got an answer and

 | confused even after re-reading the documentation on modules and writing

 | sample code.
 |
 | What are the differences between modules and Java packages?
 |
 | For example, say I have the package hello with the classes HelloWorld,
 | CommandLine, and InvalidCommandLineArgument. In Java I would put them in

 | following structure:
 |
 | |- hello/
 | |---- HelloWorld.java
 | |---- CommandLine.java
 | |---- InvalidCommandLineArgument.java
 |
 | With each file having "package hello;" at the top of the file.
 |
 | With modules it seems each file is in seperate module. Eg. "module
 | hello.HelloWorld" and then each module in the package must import any

 | modules it uses from the same package. In Java classes in the same

 | can use other classes without importing. Am I missing something?


 From the doc: "Modules have a one-to-one correspondence with source

 So I think of modules as source files. You can group modules together
 into directories and put "." as a standard directory separator.
 Like in C/C++, a source file [module] can learn about another source file
 [module] by using #include [import].
 So the grouping and syntax is similar to Java but the semantics is
 perhaps closer to C/C++.

 One difference between #include and import, though, is that #include
 makes the included file behave exactly the same as if it was typed in
 the file - which has impact on name lookup - and import only adds the
 file to a list of files to look in if the given name isn't found in
 the original file.

 -Ben

Feb 26 2004
parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Matthias Spycher" <matthias coware.com> wrote in message
news:c1liud$1dik$1 digitaldaemon.com...
 What do you think of the following extension:

 File m.d contains the module declaration

 module m : a, b, c;
 ...

 where the semantics are:

 a.d, b.d and c.d exist in the same directory as m.d and do not contain any
 public import statements.

 Thus module m consists of the unit:

 module m;
 #include a.d
 #include b.d
 #include c.d
 ...

 if we used a C preprocessor to combine the files into a single module.

 I for one would like to see the notion of a module expanded to cover
 multiple files. Comparing to my Java packages, the corresponding D file
 would otherwise be huge.

The way to bundle up bunches of modules into one unit that can be imported at once is to just make m.d import everything: m.d contains import a; import b; import c; then users would just have to import m to get all of a, b and c. How would your extension differ from this? I can't figure out what public imports have to do with it. -Ben
Feb 26 2004
parent reply "Matthias Spycher" <matthias coware.com> writes:
The idea is not to aggregate modules, but aggregate files, i.e. let a single
module span multiple files. I should have noted that the auxilliary files
a.b, b.d and c.d do not contain module delcarations and would not be
regarded as modules when m.d. is compiled.

So a private declaration in a.d, b.d or c.d is visible in m.d. Similar to
package protection in Java.

Matthias

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c1lk2b$1g9r$1 digitaldaemon.com...
 "Matthias Spycher" <matthias coware.com> wrote in message
 news:c1liud$1dik$1 digitaldaemon.com...
 What do you think of the following extension:

 File m.d contains the module declaration

 module m : a, b, c;
 ...

 where the semantics are:

 a.d, b.d and c.d exist in the same directory as m.d and do not contain


 public import statements.

 Thus module m consists of the unit:

 module m;
 #include a.d
 #include b.d
 #include c.d
 ...

 if we used a C preprocessor to combine the files into a single module.

 I for one would like to see the notion of a module expanded to cover
 multiple files. Comparing to my Java packages, the corresponding D file
 would otherwise be huge.

The way to bundle up bunches of modules into one unit that can be imported at once is to just make m.d import everything: m.d contains import a; import b; import c; then users would just have to import m to get all of a, b and c. How would your extension differ from this? I can't figure out what public imports have to do with it. -Ben

Feb 26 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthias Spycher wrote:
 The idea is not to aggregate modules, but aggregate files, i.e. let a single
 module span multiple files. I should have noted that the auxilliary files
 a.b, b.d and c.d do not contain module delcarations and would not be
 regarded as modules when m.d. is compiled.
 
 So a private declaration in a.d, b.d or c.d is visible in m.d. Similar to
 package protection in Java.

Something like an include then. It would actually be very useful when part of the code has to be generated by some other tools, and it has to be "friend" to something else. And to break up a large module (possibly a large class) into multiple source files. To avoid ambiguity, these have to have some other exptesion, like .h , .dh, or .inc. The last would cause problems with general syntax-highliting editors though, because it is alredy registered with assembly or something. Even Delphi contains include for (rare) cases, so i would think it would also be appropriate in D. -eye
Feb 26 2004
parent "Matthias Spycher" <matthias coware.com> writes:
Yes. But using the same extension '.d' would give you the option of
organizing modules and files in a very flexible manner.
A file might stand alone as a module in one application and be incorporated
into a different module in another. It may even be shared across two modules
without naming collisions -- a feature that might be useful for template
definitions.

Matthias

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c1ltha$21d8$1 digitaldaemon.com...
 Matthias Spycher wrote:
 The idea is not to aggregate modules, but aggregate files, i.e. let a


 module span multiple files. I should have noted that the auxilliary


 a.b, b.d and c.d do not contain module delcarations and would not be
 regarded as modules when m.d. is compiled.

 So a private declaration in a.d, b.d or c.d is visible in m.d. Similar


 package protection in Java.

Something like an include then. It would actually be very useful when part of the code has to be generated by some other tools, and it has to be "friend" to something else. And to break up a large module (possibly a large class) into multiple source files. To avoid ambiguity, these have to have some other exptesion, like .h , .dh, or .inc. The last would cause problems with general syntax-highliting editors though, because it is alredy registered with assembly or something. Even Delphi contains include for (rare) cases, so i would think it would also be appropriate in D. -eye

Feb 26 2004
prev sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Matthias Spycher" <matthias coware.com> wrote in message
news:c1lnes$1ope$1 digitaldaemon.com...
| The idea is not to aggregate modules, but aggregate files, i.e. let a single
| module span multiple files. I should have noted that the auxilliary files
| a.b, b.d and c.d do not contain module delcarations and would not be
| regarded as modules when m.d. is compiled.
|
| So a private declaration in a.d, b.d or c.d is visible in m.d. Similar to
| package protection in Java.
|
| Matthias

Ah, I see what you mean. The "private is visible in module" is like
C++ friend relationships. There isn't anything really like Java's
package protection. C++ deals with this by making things public -
or having lots of friends. I guess that is D's approach as well.
I haven't written anything big enough in D to complain but I tend
to agree it would be nice to have some more control over access
than just private/public/protected/export.

It could be as simple as adding "package" (or "modulepeer" or
something) as a protection keyword meaning if the given module
is foo.bar.baz then the symbol is visible in any module in foo.bar
that imports baz. Adding a keyword is usually a last resort but we
couldn't do what Java does and use no protection keyword to mean
"package" because the default protection is "public".

-Ben
Feb 26 2004
parent "Matthias Spycher" <matthias coware.com> writes:
I meant

Java package protection === D module private protection == C++ frind
relationships

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c1m467$2ent$1 digitaldaemon.com...
 "Matthias Spycher" <matthias coware.com> wrote in message
 news:c1lnes$1ope$1 digitaldaemon.com...
 | The idea is not to aggregate modules, but aggregate files, i.e. let a

 | module span multiple files. I should have noted that the auxilliary

 | a.b, b.d and c.d do not contain module delcarations and would not be
 | regarded as modules when m.d. is compiled.
 |
 | So a private declaration in a.d, b.d or c.d is visible in m.d. Similar

 | package protection in Java.
 |
 | Matthias

 Ah, I see what you mean. The "private is visible in module" is like
 C++ friend relationships. There isn't anything really like Java's
 package protection. C++ deals with this by making things public -
 or having lots of friends. I guess that is D's approach as well.
 I haven't written anything big enough in D to complain but I tend
 to agree it would be nice to have some more control over access
 than just private/public/protected/export.

 It could be as simple as adding "package" (or "modulepeer" or
 something) as a protection keyword meaning if the given module
 is foo.bar.baz then the symbol is visible in any module in foo.bar
 that imports baz. Adding a keyword is usually a last resort but we
 couldn't do what Java does and use no protection keyword to mean
 "package" because the default protection is "public".

 -Ben

Feb 26 2004