• AlanThinker (4/4) Nov 09 2014 In C#, one namespace can contains lots of classes.
• Rikki Cattermole (15/19) Nov 09 2014 You are correct, that one file can have a lot of classes in it.
• AlanThinker (15/15) Nov 09 2014 I notice that lots of GUI library will create a module which have
• Jack (7/22) Nov 09 2014 I'm not sure but importing multiple stuff(not just classes) that
• bearophile (5/6) Nov 09 2014 The file will also probably contain several free functions, and
• AlanThinker (4/10) Nov 09 2014 Is it possible to let one module contains lots of classes in
• Joakim (2/15) Nov 09 2014 Rikki gave you an example above, using packages.
• Mike Parker (38/50) Nov 09 2014 Don't think of a module as directly equivalent to a C# namespace. It is
• AlanThinker (3/3) Nov 09 2014 Yes, you are right.
• tcak (9/12) Nov 09 2014 Yes, package can do it, thou this adds burden to maintain
• AlanThinker (31/43) Nov 09 2014 If we can create partial module, it will be easier to use. then
• tcak (4/35) Nov 09 2014 That's good, but there is no need to add a new keyword as
• tcak (5/9) Nov 09 2014 Maybe this thing could open up some security issues, but if
• ketmar via Digitalmars-d (3/5) Nov 09 2014 and even compiler changes are unnecessary. `import()`, it rocks.
• tcak (5/10) Nov 09 2014 Hmm. `import()` requires filename, and -I flag. Convenience
• ketmar via Digitalmars-d (4/16) Nov 09 2014 building reasonably complex software without build system is...

"AlanThinker" <alanthinker 126.com> writes:

How to let D's one module contains lots of classes.
It seems that in D one module must in a single file.
If there all classes in one file, the file will be to big.

Rikki Cattermole <alphaglosined gmail.com> writes:

On 9/11/2014 9:44 p.m., AlanThinker wrote:

 How to let D's one module contains lots of classes.
 It seems that in D one module must in a single file.
 If there all classes in one file, the file will be to big.

You are correct, that one file can have a lot of classes in it.
But you are comparing the wrong things.


be in the same directory hierarchy.

But you can do a few things:
1) Public import other modules so that it will act as if it has it.

namespace. But in saying that, its really more directly comparable 
against java's package.
In that it is a directory that contains modules. But a package needs its 
own module (called package) that will act as basically public imports.

Here is an example of using both:
https://github.com/Devisualization/util/tree/master/source/opengl/devisualization/util/opengl/function_wrappers

Also this is more suitable for D.learn.

"AlanThinker" <alanthinker 126.com> writes:

I notice that lots of GUI library will create a module which have 
the same name as the class to hold a class. such as:
///
module tkd.widget.button;
class Button
///

If one module can have different classes in different files.
It can change to:
///
module tkd.widget;
class Button
///



D.

"Jack" <Jackoz530 gmail.com> writes:

On Sunday, 9 November 2014 at 09:17:19 UTC, AlanThinker wrote:
 I notice that lots of GUI library will create a module which 
 have the same name as the class to hold a class. such as:
 ///
 module tkd.widget.button;
 class Button
 ///

 If one module can have different classes in different files.
 It can change to:
 ///
 module tkd.widget;
 class Button
 ///



 to D.

I'm not sure but importing multiple stuff(not just classes) that 
you might not need instead of importing just what you need will 
increase bloat in your program.
So having a module for each class is better because it prevents 
unnecessary bloat.
Though that's what I understood from my prof.

"bearophile" <bearophileHUGS lycos.com> writes:

AlanThinker:

 If there all classes in one file, the file will be to big.

The file will also probably contain several free functions, and 
not just classes.

Bye,
bearophile

"AlanThinker" <alanthinker 126.com> writes:

On Sunday, 9 November 2014 at 10:02:41 UTC, bearophile wrote:
 AlanThinker:

 If there all classes in one file, the file will be to big.

 The file will also probably contain several free functions, and 
 not just classes.

 Bye,
 bearophile

Is it possible to let one module contains lots of classes in 
different files, and free functions can live in one or several 
files.

"Joakim" <dlang joakim.fea.st> writes:

On Sunday, 9 November 2014 at 10:25:36 UTC, AlanThinker wrote:
 On Sunday, 9 November 2014 at 10:02:41 UTC, bearophile wrote:
 AlanThinker:

 If there all classes in one file, the file will be to big.

 The file will also probably contain several free functions, 
 and not just classes.

 Bye,
 bearophile

 Is it possible to let one module contains lots of classes in 
 different files, and free functions can live in one or several 
 files.

Rikki gave you an example above, using packages.

Mike Parker <aldacron gmail.com> writes:

On 11/9/2014 7:25 PM, AlanThinker wrote:
 On Sunday, 9 November 2014 at 10:02:41 UTC, bearophile wrote:
 AlanThinker:

 If there all classes in one file, the file will be to big.

 The file will also probably contain several free functions, and not
 just classes.

 Bye,
 bearophile

 Is it possible to let one module contains lots of classes in different
 files, and free functions can live in one or several files.


not. A module is a single file, nothing more. You can use packages to 
group modules in multiple namespaces. If you want to have a namespace 
foo.gui with a single class per module, then here's a working example of 
something you could do:



// test/foo/gui/button.d
module foo.gui.button;

class Button
{
     public this() {
         import std.stdio : writeln;
         writeln( "New Button!" );
     }
}
// test/foo/gui/widget.d
module foo.gui.widget;

class Widget {
     public this() {
         import std.stdio : writeln;
         writeln( "New Widget!" );
     }
}
// test/foo/gui/package.d
module foo.gui;

public import foo.gui.button, foo.gui.widget;

// test/foo/namespace.d
module namespace;

import foo.gui;

void main()
{
     auto w = new foo.gui.Widget;
     auto b = new foo.gui.Button;
}



cd test
dmd namespace.d foo/gui/package.d foo/gui/widget.d foo/gui/button.d

"AlanThinker" <alanthinker 126.com> writes:

Yes, you are right.
Package can do it.
Thanks all of you!

"tcak" <tcak gmail.com> writes:

On Sunday, 9 November 2014 at 11:30:22 UTC, AlanThinker wrote:
 Yes, you are right.
 Package can do it.
 Thanks all of you!

Yes, package can do it, thou this adds burden to maintain 
packages this time. Weirdness of this design is seen in druntime 
as well.

core.sync.mutex.Mutex

Doubling mutex word unnecessarily. Every time I will create a 
module, half an hour, I am thinking what name to give the module. 
Either will create many classes in one file, or use same name for 
both module and class that causes above example.

"AlanThinker" <alanthinker 126.com> writes:

On Sunday, 9 November 2014 at 12:21:28 UTC, tcak wrote:
 On Sunday, 9 November 2014 at 11:30:22 UTC, AlanThinker wrote:
 Yes, you are right.
 Package can do it.
 Thanks all of you!

 Yes, package can do it, thou this adds burden to maintain 
 packages this time. Weirdness of this design is seen in 
 druntime as well.

 core.sync.mutex.Mutex

 Doubling mutex word unnecessarily. Every time I will create a 
 module, half an hour, I am thinking what name to give the 
 module. Either will create many classes in one file, or use 
 same name for both module and class that causes above example.

If we can create partial module, it will be easier to use. then 
no package needed.
such as:


// test/foo/gui/button.d
partial module foo.gui;

class Button
{
     public this() {
         import std.stdio : writeln;
         writeln( "New Button!" );
     }
}
// test/foo/gui/widget.d
partial module foo.gui;

class Widget {
     public this() {
         import std.stdio : writeln;
         writeln( "New Widget!" );
     }
}

// test/foo/namespace.d
module namespace;

import foo.gui;

void main()
{
     auto w = new foo.gui.Widget;
     auto b = new foo.gui.Button;
}

"tcak" <tcak gmail.com> writes:

On Sunday, 9 November 2014 at 13:17:37 UTC, AlanThinker wrote:
 On Sunday, 9 November 2014 at 12:21:28 UTC, tcak wrote:

 If we can create partial module, it will be easier to use. then 
 no package needed.
 such as:


 // test/foo/gui/button.d
 partial module foo.gui;

 class Button
 {
     public this() {
         import std.stdio : writeln;
         writeln( "New Button!" );
     }
 }
 // test/foo/gui/widget.d
 partial module foo.gui;

 class Widget {
     public this() {
         import std.stdio : writeln;
         writeln( "New Widget!" );
     }
 }

 // test/foo/namespace.d
 module namespace;

 import foo.gui;

 void main()
 {
     auto w = new foo.gui.Widget;
     auto b = new foo.gui.Button;
 }



That's good, but there is no need to add a new keyword as 
"partial" for module I think. If compiler would just merge same 
modules together automatically, that would do it.

"tcak" <tcak gmail.com> writes:

On Sunday, 9 November 2014 at 15:40:53 UTC, tcak wrote:
 On Sunday, 9 November 2014 at 13:17:37 UTC, AlanThinker wrote:

 That's good, but there is no need to add a new keyword as 
 "partial" for module I think. If compiler would just merge same 
 modules together automatically, that would do it.

Maybe this thing could open up some security issues, but if 
merging would be restricted to files in same folder, this would 
completely (99% of time) prevent problems.

* Security Issue: Same module name from a 3rd party library, etc.

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sun, 09 Nov 2014 15:40:51 +0000
tcak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That's good, but there is no need to add a new keyword as=20
 "partial" for module I think.

and even compiler changes are unnecessary. `import()`, it rocks.

"tcak" <tcak gmail.com> writes:

On Sunday, 9 November 2014 at 15:54:45 UTC, ketmar via 
Digitalmars-d wrote:
 On Sun, 09 Nov 2014 15:40:51 +0000
 tcak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That's good, but there is no need to add a new keyword as 
 "partial" for module I think.

 and even compiler changes are unnecessary. `import()`, it rocks.

Hmm. `import()` requires filename, and -I flag. Convenience 
(partial module thing) is turning into `assembly can do 
everything, no need for high level language` then.

ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sun, 09 Nov 2014 16:05:31 +0000
tcak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Sunday, 9 November 2014 at 15:54:45 UTC, ketmar via=20
 Digitalmars-d wrote:
 On Sun, 09 Nov 2014 15:40:51 +0000
 tcak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That's good, but there is no need to add a new keyword as=20
 "partial" for module I think.

 and even compiler changes are unnecessary. `import()`, it rocks.

=20
 Hmm. `import()` requires filename, and -I flag. Convenience=20
 (partial module thing) is turning into `assembly can do=20
 everything, no need for high level language` then.

building reasonably complex software without build system is...
strange. so let build system care about that.