www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - MIID Partial modules (Walter)

reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
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
Sep 20 2004
next sibling parent reply Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
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

Sep 20 2004
parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
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


Sep 20 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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
Sep 20 2004
parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
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

Sep 20 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
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


 Walter added the package keyword to satisfy those complaints. Am I on


 Have you tried using "package"?

 jcc7


Sep 20 2004
parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
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
 
 
 
 

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
Sep 20 2004
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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
Sep 20 2004
parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
Ben Hinkle wrote:

 "Sjoerd van Leent" <svanleent wanadoo.nl> wrote in message
 news:cin09f$2t4j$1 digitaldaemon.com...
 
Sjoerd van Leent 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

different classes belonging to it, I want it to be in the same module, not in different ones. I know it is possible to have a public import (just import without private) but it isn't what I am looking for. I want to make one module with multiple files, with the same properties as a normal module would have. I know it is possible (just as in C++) to have more classes in one module in a file, but I want to have the same module spread over multiple files (More like Java packages or C++ namespaces). Regards, Sjoerd
Sep 21 2004
parent reply pragma <pragma_member pathlink.com> writes:
In article <cipbtp$158g$1 digitaldaemon.com>, Sjoerd van Leent says...
No it is just a design problem. When defining a subsystem (in UML) and 
different classes belonging to it, I want it to be in the same module, 
not in different ones. I know it is possible to have a public import 
(just import without private) but it isn't what I am looking for. I want 
to make one module with multiple files, with the same properties as a 
normal module would have.

I know it is possible (just as in C++) to have more classes in one 
module in a file, but I want to have the same module spread over 
multiple files (More like Java packages or C++ namespaces).

Regards,
Sjoerd

Would it be acceptable to extend the interface pattern to your file layout? //mymodule.all import mymodule.foo1 import mymodule.foo2 import mymodule.foo3 Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it. This is functionally equivalent to what your asking for (I think anyway) while still keeping your classes spread out across multiple .d files. - Pragma [[ Eric Anderton at yahoo dot com ]]
Sep 21 2004
next sibling parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
pragma wrote:
 In article <cipbtp$158g$1 digitaldaemon.com>, Sjoerd van Leent says...
 
No it is just a design problem. When defining a subsystem (in UML) and 
different classes belonging to it, I want it to be in the same module, 
not in different ones. I know it is possible to have a public import 
(just import without private) but it isn't what I am looking for. I want 
to make one module with multiple files, with the same properties as a 
normal module would have.

I know it is possible (just as in C++) to have more classes in one 
module in a file, but I want to have the same module spread over 
multiple files (More like Java packages or C++ namespaces).

Regards,
Sjoerd

Would it be acceptable to extend the interface pattern to your file layout? //mymodule.all import mymodule.foo1 import mymodule.foo2 import mymodule.foo3 Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it. This is functionally equivalent to what your asking for (I think anyway) while still keeping your classes spread out across multiple .d files. - Pragma [[ Eric Anderton at yahoo dot com ]]

Currently it is what I am using right now. But it doesn't make me very happy. Otherwise I have to use a different code convention (such as class names after the module names etc...). Also I don't want anyone to be able importing a part of the whole, which makes things unreadable (and perhaps undesirable) in large projects. I only ask to consider/think of an extension to the system. Not that the current one is ultimately bad (even if it was, the rest of D would be a very heavy counterweight), but I think it can be even better. Before pissing off the complete newsgroup I want to say that the language itself is good in practice (though it is new) and is very easy, or should I say straightforward to learn. Where other languages need thick, heavy manuals, D can be learned with only an Internet-browser and a good set of working brains. Regards, Sjoerd
Sep 21 2004
prev sibling parent reply Benjamin Herr <ben 0x539.de> writes:
pragma wrote:
  > Would it be acceptable to extend the interface pattern to your file 
layout?
 
 //mymodule.all
 import mymodule.foo1
 import mymodule.foo2
 import mymodule.foo3
 
 Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it.  This
is
 functionally equivalent to what your asking for (I think anyway) while still
 keeping your classes spread out across multiple .d files.

If we could have a change to how module lookup works, I think it would be easier (for users) or more intuitive if you could still do just #import mymodule; dmd would look for mymodule, notice that it is a directory, and automatically proceed either including all (non-directory) files inside it, or perhaps this.d as it was suggested before, iirc, which would then include all the public import statements. - Ben
Sep 21 2004
parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
Benjamin Herr wrote:
 pragma wrote:
  > Would it be acceptable to extend the interface pattern to your file 
 layout?
 
 //mymodule.all
 import mymodule.foo1
 import mymodule.foo2
 import mymodule.foo3

 Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with 
 it.  This is
 functionally equivalent to what your asking for (I think anyway) while 
 still
 keeping your classes spread out across multiple .d files.

If we could have a change to how module lookup works, I think it would be easier (for users) or more intuitive if you could still do just #import mymodule; dmd would look for mymodule, notice that it is a directory, and automatically proceed either including all (non-directory) files inside it, or perhaps this.d as it was suggested before, iirc, which would then include all the public import statements. - Ben

I like the first solution of a Directory lookup, but D then needs to put the directory contents (well, all .d files ofcourse) into one object file. It would solve my problem quite well. Regards, Sjoerd
Sep 21 2004
prev sibling parent reply "Chr. Grade" <tickle everymail.net> writes:
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

Sep 20 2004
parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
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
Sep 20 2004