• Cameron Zemek (16/16) Feb 25 2004 Sorry to repeat this question, but I still have not got an answer and st...
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (8/29) Feb 26 2004 Not an expert here, but I don't think so. In Java everything within the
• Stewart Gordon (12/17) Feb 26 2004
• Ben Hinkle (36/36) Feb 26 2004 "Cameron Zemek" wrote in message
• Matthias Spycher (26/62) Feb 26 2004 What do you think of the following extension:
• Ben Hinkle (12/29) Feb 26 2004 The way to bundle up bunches of modules into one unit that can be import...
• Matthias Spycher (10/47) Feb 26 2004 The idea is not to aggregate modules, but aggregate files, i.e. let a si...
• Ilya Minkov (11/18) Feb 26 2004 Something like an include then. It would actually be very useful when
• Matthias Spycher (12/30) Feb 26 2004 Yes. But using the same extension '.d' would give you the option of
• Ben Hinkle (25/25) Feb 26 2004 "Matthias Spycher" wrote in message
• Matthias Spycher (8/33) Feb 26 2004 I meant

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?

=?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

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?

<snip>

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.

"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

"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

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

"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

"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


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

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

"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


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

"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

"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

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