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:
























The master file could then be used as:













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






./master/first.d





./master/second.d





./main.d










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:
 






 







 







 
 The master file could then be used as:
 











 
 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





 
 ./master/first.d




 
 ./master/second.d




 
 ./main.d









 
 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:
























 The master file could then be used as:













 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




thought

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




crack?

 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
 
 
 
 


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


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






 







 







 
 The master file could then be used as:
 











 
 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