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?

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

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.

"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

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

"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

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

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

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

"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