In C#, one namespace can contains lots of classes.
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.

On 9/11/2014 9:44 p.m., AlanThinker wrote:
> In C#, one namespace can contains lots of classes.
> 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.

A namespace in c# can be between multiple files that don't even need to 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.
2) Use packages. This is probably the most comparable against a c# 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.

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

If someone want port a C# library to D, it will helpful to keep D code and C# same. then library user can port there app easily to D.

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
> ///
>
> If someone want port a C# library to D, it will helpful to keep D code and C# same. then library user can port there app easily 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.

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

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.

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.

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.

Don't think of a module as directly equivalent to a C# namespace. It is 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

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

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.