Hi all,

Currently, D only supports modules on the file level. For small modules this is fine, but for modules with classes it isn't pretty working. Currently without splitting up the modules per class, files become extensively long.

As I am working on a school project with D (we may use our own languages, if argumented well :) ) and also use it for myself, I constantly struggle with very long files, searching for things become sometimes a little disaster.

Splitting modules per class isn't a good design and weakens the whole idea behind modulair (subsystem) engineering. This is why I ask to consider building in something like partial or dictating modules. The system I have in mind takes uses a master module (or simply a module) and dictates which child modules may be a child of it.

Similar to the following:

# file master.d:
# ----------------------------------------------------------------------
# module master;
#
# import child first;    // refers to first.d
# import child second;   // refers to second.d

# file first.d:
# ----------------------------------------------------------------------
# child first module master;
#
# class SomeClass {
#     ...
# }

# file second.d:
# ----------------------------------------------------------------------
# child second module master;
#
# class SomeOtherClass {
#     ...
# }

The master file could then be used as:

# file main.d:
# ----------------------------------------------------------------------
# module main;
#
# void main(char[][] args) {
#     // ctors master[first].SomeClass
#     SomeClass sc = new SomeClass();
#
#     // ctors master[second].SomeOtherClass
#     SomeOtherClass sc = new SomeOtherClass();
# }

Regards,
Sjoerd

Is this what you are trying to do?

./master/all.d
# ----------------------------------------------------------------------
# module master.all;
#
# import master.first;
# import master.second;

./master/first.d
# ----------------------------------------------------------------------
# module master.first;
#
# class SomeClass {}

./master/second.d
# ----------------------------------------------------------------------
# module master.second;
#
# class SomeOtherClass {}

./main.d
# ----------------------------------------------------------------------
# import master.all;
#
# void main(char[][] args) {
#     // ctors master.first.SomeClass
#     SomeClass sc1 = new SomeClass();
#     // ctors master.second.SomeOtherClass
#     SomeOtherClass sc2 = new SomeOtherClass();
# }

Compile like so:
dmd main.d master/first.d master/second.d


Cheers,
Bastiaan.


Sjoerd van Leent wrote:
> Hi all,
> 
> Currently, D only supports modules on the file level. For small modules this is fine, but for modules with classes it isn't pretty working. Currently without splitting up the modules per class, files become extensively long.
> 
> As I am working on a school project with D (we may use our own languages, if argumented well :) ) and also use it for myself, I constantly struggle with very long files, searching for things become sometimes a little disaster.
> 
> Splitting modules per class isn't a good design and weakens the whole idea behind modulair (subsystem) engineering. This is why I ask to consider building in something like partial or dictating modules. The system I have in mind takes uses a master module (or simply a module) and dictates which child modules may be a child of it.
> 
> Similar to the following:
> 
> # file master.d:
> # ----------------------------------------------------------------------
> # module master;
> #
> # import child first;    // refers to first.d
> # import child second;   // refers to second.d
> 
> # file first.d:
> # ----------------------------------------------------------------------
> # child first module master;
> #
> # class SomeClass {
> #     ...
> # }
> 
> # file second.d:
> # ----------------------------------------------------------------------
> # child second module master;
> #
> # class SomeOtherClass {
> #     ...
> # }
> 
> The master file could then be used as:
> 
> # file main.d:
> # ----------------------------------------------------------------------
> # module main;
> #
> # void main(char[][] args) {
> #     // ctors master[first].SomeClass
> #     SomeClass sc = new SomeClass();
> #
> #     // ctors master[second].SomeOtherClass
> #     SomeOtherClass sc = new SomeOtherClass();
> # }
> 
> Regards,
> Sjoerd

Bastiaan Veelo wrote:

No this is different, I know it is possible of course. I don't mean this, because you are making submodules for every class, which is just the opposite from what I mean.

For example, in Java it is possible to import a package with let's say 10 classes. Every class is split up in a file. In D you'll have to write one file containing 10 classes (which becomes very large) or you need to split them up *into other modules*, but that weakens modulair design, and is for large projects a pitfall.

> Is this what you are trying to do?
> 
> ./master/all.d
> # ----------------------------------------------------------------------
> # module master.all;
> #
> # import master.first;
> # import master.second;
> 
> ./master/first.d
> # ----------------------------------------------------------------------
> # module master.first;
> #
> # class SomeClass {}
> 
> ./master/second.d
> # ----------------------------------------------------------------------
> # module master.second;
> #
> # class SomeOtherClass {}
> 
> ./main.d
> # ----------------------------------------------------------------------
> # import master.all;
> #
> # void main(char[][] args) {
> #     // ctors master.first.SomeClass
> #     SomeClass sc1 = new SomeClass();
> #     // ctors master.second.SomeOtherClass
> #     SomeOtherClass sc2 = new SomeOtherClass();
> # }
> 
> Compile like so:
> dmd main.d master/first.d master/second.d
> 
> 
> Cheers,
> Bastiaan.
> 
> 
> Sjoerd van Leent wrote:
> 
>> Hi all,
>>
>> Currently, D only supports modules on the file level. For small modules this is fine, but for modules with classes it isn't pretty working. Currently without splitting up the modules per class, files become extensively long.
>>
>> As I am working on a school project with D (we may use our own languages, if argumented well :) ) and also use it for myself, I constantly struggle with very long files, searching for things become sometimes a little disaster.
>>
>> Splitting modules per class isn't a good design and weakens the whole idea behind modulair (subsystem) engineering. This is why I ask to consider building in something like partial or dictating modules. The system I have in mind takes uses a master module (or simply a module) and dictates which child modules may be a child of it.
>>
>> Similar to the following:
>>
>> # file master.d:
>> # ----------------------------------------------------------------------
>> # module master;
>> #
>> # import child first;    // refers to first.d
>> # import child second;   // refers to second.d
>>
>> # file first.d:
>> # ----------------------------------------------------------------------
>> # child first module master;
>> #
>> # class SomeClass {
>> #     ...
>> # }
>>
>> # file second.d:
>> # ----------------------------------------------------------------------
>> # child second module master;
>> #
>> # class SomeOtherClass {
>> #     ...
>> # }
>>
>> The master file could then be used as:
>>
>> # file main.d:
>> # ----------------------------------------------------------------------
>> # module main;
>> #
>> # void main(char[][] args) {
>> #     // ctors master[first].SomeClass
>> #     SomeClass sc = new SomeClass();
>> #
>> #     // ctors master[second].SomeOtherClass
>> #     SomeOtherClass sc = new SomeOtherClass();
>> # }
>>
>> Regards,
>> Sjoerd

In article <cin09f$2t4j$1@digitaldaemon.com>, Sjoerd van Leent says...
>
>Bastiaan Veelo wrote:
>
>No this is different, I know it is possible of course. I don't mean this, because you are making submodules for every class, which is just the opposite from what I mean.
>
>For example, in Java it is possible to import a package with let's say 10 classes. Every class is split up in a file. In D you'll have to write one file containing 10 classes (which becomes very large) or you need to split them up *into other modules*, but that weakens modulair design, and is for large projects a pitfall.

I have a strong feeling that I've read these complaints before. And I thought Walter added the package keyword to satisfy those complaints. Am I on crack?

Have you tried using "package"?

jcc7

Isn't it private what you are talking about? This is not what I meant. If otherwise, please let me know.

Regards,
Sjoerd

J C Calvarese wrote:
> 
> I have a strong feeling that I've read these complaints before. And I thought
> Walter added the package keyword to satisfy those complaints. Am I on crack?
> 
> Have you tried using "package"? 
> 
> jcc7

I partially agree. But I think it's the C++ namespaces missing.
D lacks a facility which enables code management, grouping or subgrouping, for the purpose of better readability and recognizability.

Chr. Grade

Sjoerd van Leent wrote:
> Hi all,
> 
> Currently, D only supports modules on the file level. For small modules this is fine, but for modules with classes it isn't pretty working. Currently without splitting up the modules per class, files become extensively long.
> 
> As I am working on a school project with D (we may use our own languages, if argumented well :) ) and also use it for myself, I constantly struggle with very long files, searching for things become sometimes a little disaster.
> 
> Splitting modules per class isn't a good design and weakens the whole idea behind modulair (subsystem) engineering. This is why I ask to consider building in something like partial or dictating modules. The system I have in mind takes uses a master module (or simply a module) and dictates which child modules may be a child of it.
> 
> Similar to the following:
> 
> # file master.d:
> # ----------------------------------------------------------------------
> # module master;
> #
> # import child first;    // refers to first.d
> # import child second;   // refers to second.d
> 
> # file first.d:
> # ----------------------------------------------------------------------
> # child first module master;
> #
> # class SomeClass {
> #     ...
> # }
> 
> # file second.d:
> # ----------------------------------------------------------------------
> # child second module master;
> #
> # class SomeOtherClass {
> #     ...
> # }
> 
> The master file could then be used as:
> 
> # file main.d:
> # ----------------------------------------------------------------------
> # module main;
> #
> # void main(char[][] args) {
> #     // ctors master[first].SomeClass
> #     SomeClass sc = new SomeClass();
> #
> #     // ctors master[second].SomeOtherClass
> #     SomeOtherClass sc = new SomeOtherClass();
> # }
> 
> Regards,
> Sjoerd

search the page http://www.digitalmars.com/d/attribute.html for "package". For the definition of packages see the module.html help

"Sjoerd van Leent" <svanleent@wanadoo.nl> wrote in message news:cin4tp$2ve6$1@digitaldaemon.com...
> Isn't it private what you are talking about? This is not what I meant. If otherwise, please let me know.
>
> Regards,
> Sjoerd
>
> J C Calvarese wrote:
> >
> > I have a strong feeling that I've read these complaints before. And I
thought
> > Walter added the package keyword to satisfy those complaints. Am I on
crack?
> >
> > Have you tried using "package"?
> >
> > jcc7

Ben Hinkle wrote:
> search the page http://www.digitalmars.com/d/attribute.html for "package".
> For the definition of packages see the module.html help
> 
> 
> 
> 
As I understand package is a protection attribute not different from private, protected and public. It means that your submodules can use your package classes/functions/etcetera but other modules can't. Granted, it is a nice feature, but not what I'm looking for.

Though you did learn me a new keyword, that I appreciate!

Regards,
Sjoerd

Chr. Grade wrote:

> 
> I partially agree. But I think it's the C++ namespaces missing.
> D lacks a facility which enables code management, grouping or subgrouping, for the purpose of better readability and recognizability.
> 
> Chr. Grade
> 

I think the notation as done in D is better, since you don't have to do something odd as:

namespace x { namespace y { namespace z {
	...code...
}}}

And I still think that the C++ namespace protection system is not well designed, it is possible to append files to a namespace when wanted. I think that a parent namespace needs to be in control of this. For the rest I agree.

Regards,
Sjoerd

"Sjoerd van Leent" <svanleent@wanadoo.nl> wrote in message news:cin09f$2t4j$1@digitaldaemon.com...
> Bastiaan Veelo wrote:
>
> No this is different, I know it is possible of course. I don't mean this, because you are making submodules for every class, which is just the opposite from what I mean.
>
> For example, in Java it is possible to import a package with let's say 10 classes. Every class is split up in a file. In D you'll have to write one file containing 10 classes (which becomes very large) or you need to split them up *into other modules*, but that weakens modulair design, and is for large projects a pitfall.

In D you can have any number of classes per file. The only difference between putting two classes in one module and putting two classes in two modules in the same package is that private variables are no longer shared and that was why Walter introduced package scope. Plus I suppose one has to "import" two modules instead of one but that is a trivial difference. I don't understand why you feel the need to have one huge file containing lots of classes. Are you worrying about people importing only one of the modules in the package?

-Ben