www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to break module into multiple file.

reply Matthew Ong <ongbp yahoo.com> writes:
Hi,

According to:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=135947

And also source code within dmd2/src
It seems that there is only one file per module.



If yes, most name spaced programming language allow breaking of single module
into multiple
file to store various logically linked class and separate them when they are
not.

Like module Collection may have:
Common interfaces for both HashMap, LinkedList and hashlist.

But they should be all be in different source file(HashMap.d, LinkedList.d,
HashList.d) but
logically within the same module collection.(Directory)
How do I do that within D? what is the directory layout of the project?

Matthew Ong
May 12 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Use folders as a collection of modules.

foo/bar.d => import foo.bar;

You don't actually have to separate them into folders - the directory
layout is up to you. But this is the simplest method.

Learn more here:

http://digitalmars.com/d/2.0/module.html
May 12 2011
parent Matthew Ong <ongbp yahoo.com> writes:
Hi Adam,

Ok. Just to be very clear here. Please help to validate.

Common interfaces for both HashMap, LinkedList and hashlist.
But they should be all be in different source file(HashMap.d, >LinkedList.d,
HashList.d).. To have import for: module CornerCube.Collections class HashMap{...} I would have to layout as: MyLib/Collection.d << HashMap, LinkedList, HashList within this file The single Collection.d works for me but hard to maintain manually. For this one I use import MyLib.Collection; or MyLib/Collections/HashMap.d << Single class file. but module Corner CornerCube/Collection/LinkedList.d CornerCube/Collection/HashList.d This one I have error. import MyLib.Collection; This also I have error. import MyLib.Collection.LinkedList; import MyLib.Collection.HashList; // Some sort of recursive import... How do I import them within the calling class?
May 12 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-12 06:33, Matthew Ong wrote:
 Hi,
 
 According to:
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group
 =digitalmars.D&artnum=135947
 
 And also source code within dmd2/src
 It seems that there is only one file per module.
 

 
 If yes, most name spaced programming language allow breaking of single
 module into multiple
 file to store various logically linked class and separate them when they
 are not.
 
 Like module Collection may have:
 Common interfaces for both HashMap, LinkedList and hashlist.
 
 But they should be all be in different source file(HashMap.d, LinkedList.d,
 HashList.d) but
 logically within the same module collection.(Directory)
 How do I do that within D? what is the directory layout of the project?
A module is always one file and only one file. However, a module can publically import another module (the default import is private) and then any module that imports that module will also import the modules that that module publically imports. Just stick public in front of an import to make it public. Any modules within the same directory are within the same package, so they would then share package access if you share the package access modifier, but there's no way to impor them as a group. Modules are always imported individually. The closest you ever get to being able to import them as a group is if you have a module which publically imports other modules, and you import that module. - Jonathan M Davis
May 12 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 12.05.2011 17:05, Jonathan M Davis wrote:

 A module is always one file and only one file.
...which could be really, really big due to this limitation (std.datetime), and this is not always convenient sometimes - that's why I like the idea of namespaces and partial classes. There is another inconvenience with D modules - compiler will *always* split module name into file system path when searching, so I couldn't have different namespaces (on different levels) in single directory, and this also forces me to match file name with module name. Sure, somehow this is good - but not always, as it makes splitting of one logical module into several physical pieces quite hard. The idea of enforcing specific style of code grouping and organization is not quite good, IMHO. However, there is a nice trick using mixin(import("file-to-include")) - which could really help sometimes :) /Alexander
May 12 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
 so I couldn't have different namespaces (on different levels) in
 single directory, and this also forces me to match file
 name with module name.
No, it doesn't. You're right that it splits when it searches, but it doesn't *have* to search. If you use the module declaration at the top of the file and manually list the files on the command line, the file and directory names don't matter. a.d ==== import cool.wtf; void main() {} ==== b.d ==== module cool.wtf; ====
May 12 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 12.05.2011 19:53, Adam Ruppe wrote:

 If you use the module declaration at the top of the file and manually
 list the files on the command line, the file and directory names don't
 matter.
Right, but this, in turn, forces me to recompile all of my modules after every change, no matter where :) For small projects this is OK, but for large - not quite, IMHO. /Alexander
May 12 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 For small projects this is OK, but for large - not quite, IMHO.
I don't know about that. I always compile everything at once now - in my experience, it's negligibly slower than linking alone. druntime: compiled all at once takes ~1 second on my box. 65k lines of (light) code. phobos: compiled all at once takes ~1 second. 150k loc. my web app for work: 3 seconds, all at once. 50k loc, does some crazy stuff. Maybe million line programs will be unacceptably slow, but I don't know, I'd have to actually see it being a problem in practice before I get worked up about it. tbh I wouldn't be surprised if the incremental build was actually slower than the all at once in a lot of situations. (Though, naming the packages and modules to match the filesystem is a small cost anyway - it makes it easier to find the files so usually the best choice anyway.)
May 12 2011
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 12/05/2011 19:25, Adam Ruppe wrote:
 Maybe million line programs will be unacceptably slow, but I don't
 know, I'd have to actually see it being a problem in practice
 before I get worked up about it. tbh I wouldn't be surprised if
 the incremental build was actually slower than the all at once in
 a lot of situations.
It's a lot slower in almost all situations I've encountered... It's also buggier due to templates only being emitted once (though I've never run into this issue personally, I know others have).
 (Though, naming the packages and modules to match the filesystem is
 a small cost anyway - it makes it easier to find the files so usually
 the best choice anyway.)
-- Robert http://octarineparrot.com/
May 12 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 For small projects this is OK, but for large - not quite, IMHO.
I don't know about that. I always compile everything at once now - in my experience, it's negligibly slower than linking alone. druntime: compiled all at once takes ~1 second on my box. 65k lines of (light) code. phobos: compiled all at once takes ~1 second. 150k loc. my web app for work: 3 seconds, all at once. 50k loc, does some crazy stuff. Maybe million line programs will be unacceptably slow, but I don't know, I'd have to actually see it being a problem in practice before I get worked up about it. tbh I wouldn't be surprised if the incremental build was actually slower than the all at once in a lot of situations. (Though, naming the packages and modules to match the filesystem is a small cost anyway - it makes it easier to find the files so usually the best choice anyway.)
It was designed that way to make finding and managing the files easier. The compiler is actually able to locate modules easily and reliably. It's generally easy for _you_ to find them too, because the import tells you where they are (the fact that you can have multiply directories being searched for imports being the main complicating factor). It's what pretty much any D programmer will expect. Doing anything else will just cause confusion. Sure, you can do whatever you want with your own code, but I would definitely advise just following the normal directory structure with modules rather than trying to mess around with it. It is the way that it is for a reason. - Jonathan M Davis
May 12 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 12.05.2011 20:34, Jonathan M Davis wrote:

 It's generally easy for _you_ to find them too, because the import tells you
where 
 they are (the fact that you can have multiply directories being searched for 
 imports being the main complicating factor). It's what pretty much any D 
 programmer will expect. Doing anything else will just cause confusion.
For those who are started with D, or had something similar before - probably. But not for all people this is natural way to handle their sources. In general, I agree, the reasoning is good enough - I follow it. One thing though is really annoying (to me, at least) with this binding to file name - if file is named with dashes, compiler wouldn't find it by itself. For those who prefer underscores this is not a problem, of course. /Alexander
May 12 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 12.05.2011 20:34, Jonathan M Davis wrote:
 It's generally easy for _you_ to find them too, because the import tells
 you where they are (the fact that you can have multiply directories
 being searched for imports being the main complicating factor). It's
 what pretty much any D programmer will expect. Doing anything else will
 just cause confusion.
For those who are started with D, or had something similar before - probably. But not for all people this is natural way to handle their sources. In general, I agree, the reasoning is good enough - I follow it. One thing though is really annoying (to me, at least) with this binding to file name - if file is named with dashes, compiler wouldn't find it by itself. For those who prefer underscores this is not a problem, of course.
Dashes aren't legal in module names, because they're not legal in indentifier names. However, if you insist on naming your files that way for whatever reason, you can always put dashes in the file name and just name the module appropriately with the module statement at the top of the file. As long as the names are close (like the module name with underscores and the file with dashes), it shouldn't pose much problem for programmers, and the compiler can find them just fine. Still, I wouldn't have though that dashes would have been a big enough deal to really care. I would have thought that you'd name the module whatever made sense for the code and then just name the file accordingly. However, the module statement does allow you to make them not match if you really want to, so that situtation has been designed for. - Jonathan M Davis
May 12 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 13.05.2011 00:59, Jonathan M Davis wrote:

 Still, I wouldn't have though that dashes would have been a big enough deal to
really care.
I didn't say that this is a "big deal", just "inconvenience". There are many minor things which are not a big deal, but make life a bit less convenient - and this is the exact reason why we have so many programming languages, libraries etc :) /Alexander
May 13 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/13/2011 3:51 PM, Alexander wrote:
 On 13.05.2011 00:59, Jonathan M Davis wrote:

 Still, I wouldn't have though that dashes would have been a big enough deal to
really care.
I didn't say that this is a "big deal", just "inconvenience". There are many minor things which are not a big deal, but make life a bit less convenient - and this is the exact reason why we have so many programming languages, libraries etc :) /Alexander
I agreed with what alexander is voicing out. How about the process within a team development. That current D layout seem to limit that one file to a single developer. Instead of multiple class multiple developer within the same module. Using the example: HashMap & Unit tested implemented by matthew LinkedList & Unit tested implemented by john but the same module is handled by Jonathan for other classes? Perhaps some one can show how this is done with Subversion / CVS for this team? -- Matthew Ong email: ongbp yahoo.com
May 18 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 5/13/2011 3:51 PM, Alexander wrote:
 On 13.05.2011 00:59, Jonathan M Davis wrote:
 Still, I wouldn't have though that dashes would have been a big enough
 deal to really care.
 
I didn't say that this is a "big deal", just "inconvenience". There are many minor things which are not a big deal, but make life a bit less convenient - and this is the exact reason why we have so many programming languages, libraries etc :) /Alexander
I agreed with what alexander is voicing out. How about the process within a team development. That current D layout seem to limit that one file to a single developer. Instead of multiple class multiple developer within the same module. Using the example: HashMap & Unit tested implemented by matthew LinkedList & Unit tested implemented by john but the same module is handled by Jonathan for other classes? Perhaps some one can show how this is done with Subversion / CVS for this team?e
It's the same as in many other languages - including heavily used languages such as C and C++. Restricting files such that you're only allowed to have one (though there are probably other languages out there that do the same). D doesn't have that restriction. And even if it did, it's still quite possible to have multiple people working on the same file at once. Pretty much any modern source control system is set up so that you can have multiple people working on the same file at once. If multiple people are making major changes at the same time, it can be problematic when they have to merge their changes, but it's completely doable and happens often enough in real developement enviroments. What D does is completely normal and common. It just doesn't - Jonathan M Davis
May 18 2011
next sibling parent reply Alexander <aldem+dmars nk7.net> writes:
On 18.05.2011 19:10, Jonathan M Davis wrote:


To be honest, I didn't see any single source file with ca. 30000 lines in it (like std.datetime) for quite a while :) Probably, I am old-fashioned, but this amount of code in single file makes things less manageable, even if everything in this single file is somehow related to each other. /Alexander
May 18 2011
parent Adam Burton <adz21c gmail.com> writes:
Alexander wrote:

 On 18.05.2011 19:10, Jonathan M Davis wrote:
 
 What D does is completely normal and common. It just doesn't match Java

To be honest, I didn't see any single source file with ca. 30000 lines in it (like std.datetime) for quite a while :) Probably, I am old-fashioned, but this amount of code in single file makes things less manageable, even if everything in this single file is somehow related to each other. /Alexander
Personally I think this is where IDE developers are getting away with being lazy. Rather than abstracting the file system away from code and letting the user choose to see code at a class level or module level (so we work with code on its abstract concepts) they just open a file. Yes they offer tools to let you jump around the file to types you want but then you spend time looking for the line of code you want before you jump back to another type and find that line again (unless they offer line bookmarks). With multiple files you can have both types open and leave each file at the 2 lines you jump between. On the other hand though what happens if I am in a single large type and moving between 2 methods? The same problem again. IDEs should be fixing this for us.
May 18 2011
prev sibling parent Adam Burton <adz21c gmail.com> writes:
Jonathan M Davis wrote:

 On 5/13/2011 3:51 PM, Alexander wrote:
 On 13.05.2011 00:59, Jonathan M Davis wrote:
 Still, I wouldn't have though that dashes would have been a big enough
 deal to really care.
 
I didn't say that this is a "big deal", just "inconvenience". There are many minor things which are not a big deal, but make life a bit less convenient - and this is the exact reason why we have so many programming languages, libraries etc :) /Alexander
I agreed with what alexander is voicing out. How about the process within a team development. That current D layout seem to limit that one file to a single developer. Instead of multiple class multiple developer within the same module. Using the example: HashMap & Unit tested implemented by matthew LinkedList & Unit tested implemented by john but the same module is handled by Jonathan for other classes? Perhaps some one can show how this is done with Subversion / CVS for this team?e
It's the same as in many other languages - including heavily used languages such as C and C++. Restricting files such that you're only do to my knowledge (though there are probably other languages out there that do the same). D doesn't have that restriction. And even if it did, it's still quite possible to have multiple people working on the same file at once. Pretty much any modern source control system is set up so that you can have multiple people working on the same file at once. If multiple people are making major changes at the same time, it can be problematic when they have to merge their changes, but it's completely doable and happens often enough in real developement enviroments. What D does is - Jonathan M Davis
have multiple classes in one file. It kind of has too because you can declare a delegate type and that would be crazy in just one file. namespace Bob { public delegate void Eat(int bleh); // Or something like this // I don't remember the exact syntax public class Cheese{} } Visual studio just doesn't encourage that style of file management. If you look I am pretty sure there is a file template just called "Code". Most people when creating a new file though intend to create a class or an interface so it gets overlooked. I do tend to prefer the multiple file approach. I find if I have a large file with lots code in it I having to jump around the file too much, it also can just seem a bit daunting to open. Additionally while you can have more than one person editing a file in source control at any time I find that if someone makes a reasonably large change to a file then even though you don't touch the same code you can still get merge issues, them merge tools are not perfect. On the other hand the one large file approach makes sense since you can declare variables outside class definitions in D, so if you spread across multiple files you start wondering which file did you declare it in? Also module constructors. We'd have to add complexity by having a fixed file name for some stuff or at least create a convention (for people not too follow). Over all though I don't think it is a big issue. Merge issues are easy to resolve and editors have bookmark functionality or multiple views on a file (which can have its own issues). So I just have to man up when the file is big ;-). Adam
May 18 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Matthew Ong Wrote:

 I agreed with what alexander is voicing out. How about the process 
 within a team development. That current D layout seem to limit that one 
 file to a single developer. Instead of multiple class multiple developer 
 within the same module.
 Using the example:
 HashMap & Unit tested implemented by matthew
 LinkedList & Unit tested implemented by john
 but the same module is handled by Jonathan for other classes?
 
 Perhaps some one can show how this is done with Subversion / CVS for 
 this team?
There is no reason Mathew and John can't implement those in the same file, at the same time. Well assuming your using a CVS. Mathew: svn checkout // change stuff John: svn checkout // change stuff Mathew: svn commit // change stuff John: svn commit svn update svn commit // change stuff Mathew: svn commit svn update svn commit
May 18 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Alexander" <aldem+dmars nk7.net> wrote in message 
news:iqh6gk$hpn$1 digitalmars.com...
 On 12.05.2011 17:05, Jonathan M Davis wrote:

 A module is always one file and only one file.
...which could be really, really big due to this limitation (std.datetime), and this is not always convenient sometimes - that's why I like the idea of namespaces and partial classes.
...
  However, there is a nice trick using mixin(import("file-to-include")) - 
 which could really help sometimes :)
One could also just use public imports. Although using public imports for this sort of situation would probably would work even better if modules were allowed to have the same name as packages. I have no idea how difficult that would be to implement in DMD, though.
May 12 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Matthew Ong" <ongbp yahoo.com> wrote in message 
news:iqgnj9$2n0j$1 digitalmars.com...
 Hi,

 According to:
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=135947

 And also source code within dmd2/src
 It seems that there is only one file per module.



 If yes, most name spaced programming language allow breaking of single 
 module
 into multiple
 file to store various logically linked class and separate them when they 
 are not.

 Like module Collection may have:
 Common interfaces for both HashMap, LinkedList and hashlist.

 But they should be all be in different source file(HashMap.d, 
 LinkedList.d,
 HashList.d) but
 logically within the same module collection.(Directory)
 How do I do that within D? what is the directory layout of the project?
--- Convert this... --- // libfoo.d module libfoo; void a() {} void b() {} void c() {} // main.d import libfoo; void main() { a(); b(); c(); } -- ...to this: --- // libfoo/all.d module libfoo.all; public import libfoo.partA; public import libfoo.partB; public import libfoo.partC; // libfoo/partA.d module libfoo.partA; void a() {} // libfoo/partB.d module libfoo.partB; void b() {} // libfoo/partC.d module libfoo.partC; void c() {} // main.d import libfoo.all; void main() { a(); b(); c(); }
May 12 2011
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
I wonder a bit why you want one file per object? Is it to avoid unnecessary
imports? Make finding object definitions easier? Or a style preference? I think
replies by others covered all but the first question. I use the "import
std.foo: bar, baz;" syntax for that.

Generally speaking, separating unrelated code is a good idea, but I think
closely coupled code should go in the same file. I've heard that circular
imports are buggy in D.

Matthew Ong Wrote:

 Hi,
 
 According to:
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=135947
 
 And also source code within dmd2/src
 It seems that there is only one file per module.
 

 
 If yes, most name spaced programming language allow breaking of single module
 into multiple
 file to store various logically linked class and separate them when they are
not.
 
 Like module Collection may have:
 Common interfaces for both HashMap, LinkedList and hashlist.
 
 But they should be all be in different source file(HashMap.d, LinkedList.d,
 HashList.d) but
 logically within the same module collection.(Directory)
 How do I do that within D? what is the directory layout of the project?
 
 Matthew Ong
May 13 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:iqjamt$1e5b$1 digitalmars.com...
I wonder a bit why you want one file per object? Is it to avoid unnecessary 
imports? Make finding object definitions easier? Or a style preference? I 
think replies by others covered all but the first question. I use the 
"import std.foo: bar, baz;" syntax for that.

 Generally speaking, separating unrelated code is a good idea, but I think 
 closely coupled code should go in the same file. I've heard that circular 
 imports are buggy in D.
I don't think it's as bad with the newer versions of DMD as it used to be. As far as I can tell, the main problem with circular imports now is just when two modules in the cycle both have static constructors. Although there are at least known ways to work around that (there was a thread about that not too long ago, don't remember the name of it, but I was the original poster, in case that helps finding it). But yea, one-class-per-file is really a Java thing (and then a few other languages kind of ape'd it.). No need to force youself into that in D.
May 13 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/14/2011 3:17 AM, Nick Sabalausky wrote:
 "Jason House"<jason.james.house gmail.com>  wrote in message
 But yea, one-class-per-file is really a Java thing (and then a few other
Not true entirely, the limit is one public class per file. There is no actual limit for such: // The file must be ClassA.java public class ClassA{} class ClassB1{} class ClassB2{} class ClassB3{} class ClassB4{}...
 languages kind of ape'd it.). No need to force youself into that in D.
As for the real reason it is for: That current D layout seem to limit that one file to a single developer. Instead of multiple classes by multiple developers within the same module. Using the example: HashMap & Unit tested implemented by matthew LinkedList & Unit tested implemented by john but the same module is handled by Jonathan for other classes? But Nick, -- ...to this: --- // libfoo/all.d module libfoo.all; public import libfoo.partA; public import libfoo.partB; public import libfoo.partC; That does the trick. Now my only concern is that when does D linked like C++ or dynamic selective linked on import that is ONLY really used and not linked ALL that is imported....Such thing does not happen in Java because linking is done during runtime by Class Loader. I wonder the loader in D for DLL is as intelligent. -- Matthew Ong email: ongbp yahoo.com
May 19 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Matthew Ong" <ongbp yahoo.com> wrote in message 
news:ir3801$84b$1 digitalmars.com...
 On 5/14/2011 3:17 AM, Nick Sabalausky wrote:
 "Jason House"<jason.james.house gmail.com>  wrote in message
 But yea, one-class-per-file is really a Java thing (and then a few other
Not true entirely, the limit is one public class per file. There is no actual limit for such: // The file must be ClassA.java public class ClassA{} class ClassB1{} class ClassB2{} class ClassB3{} class ClassB4{}...
I see. But in any case, D allows multiple public classes in one file, FWIW.
 languages kind of ape'd it.). No need to force youself into that in D.
As for the real reason it is for: That current D layout seem to limit that one file to a single developer. Instead of multiple classes by multiple developers within the same module. Using the example: HashMap & Unit tested implemented by matthew LinkedList & Unit tested implemented by john but the same module is handled by Jonathan for other classes?
That's what version control systems are for. As long as you're using a VCS that isn't terrible (ie, as long as you're not using CVS or Visual SourceSafe), than it's easy for multiple people to edit the same source file.
 But Nick,
 -- ...to this: ---

 // libfoo/all.d
 module libfoo.all;
 public import libfoo.partA;
 public import libfoo.partB;
 public import libfoo.partC;

 That does the trick.
Great :)
 Now my only concern is that when does D linked like C++ or dynamic 
 selective linked on import that is ONLY really used and not linked ALL 
 that is imported....Such thing does not happen in Java because linking is 
 done during runtime by Class Loader. I wonder the loader in D for DLL is 
 as intelligent.
AIUI, automatic DLL loading is handled by windows, not D (but I think you can also load DLLs manually). Also, D is usually linked statically, not dynamically. I know it's possible for a static linker to eliminate code that's not used, but I don't think OPTLINK (D's linker on windows) currently does it.
May 19 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/20/2011 4:23 AM, Nick Sabalausky wrote:
 "Matthew Ong"<ongbp yahoo.com>  wrote in message
 news:ir3801$84b$1 digitalmars.com...
 On 5/14/2011 3:17 AM, Nick Sabalausky wrote:
 "Jason House"<jason.james.house gmail.com>   wrote in message
 But yea, one-class-per-file is really a Java thing (and then a few other
Not true entirely, the limit is one public class per file. There is no actual limit for such: // The file must be ClassA.java public class ClassA{} class ClassB1{} class ClassB2{} class ClassB3{} class ClassB4{}...
 I see. But in any case, D allows multiple public classes in one file, FWIW.
Yes. I agree that the multiple public class per file is good. I can the uses of that when it does not come into library but in Web Page Rendering, Business Logic Layer and GUI Logic Layer(Java really messes thing up here for swing GUI.)
 languages kind of ape'd it.). No need to force youself into that in D.
As for the real reason it is for: That current D layout seem to limit that one file to a single developer. Instead of multiple classes by multiple developers within the same module. Using the example: HashMap& Unit tested implemented by matthew LinkedList& Unit tested implemented by john but the same module is handled by Jonathan for other classes?
That's what version control systems are for. As long as you're using a VCS that isn't terrible (ie, as long as you're not using CVS or Visual SourceSafe), than it's easy for multiple people to edit the same source file.
OK. I read somewhere else about this, I think there is same issue for SubVersion? Someone suggested Hg. But that does not work well for some security centric applications like where they divide up even the accountability of the developer to the code. How can someone proof that if multiple person changes the same peace of code. Like in Defence and Banking people might ask this questions.
 But Nick,
 -- ...to this: ---

 // libfoo/all.d
 module libfoo.all;
 public import libfoo.partA;
 public import libfoo.partB;
 public import libfoo.partC;

 That does the trick.
Great :)
The breaking up allow me to even hide some class that I do not want. I think I begin to understand how D does its package/module layout. Using the approach that you shown here, allow me to think about how to migrate some of the Java API I have coded.
 Now my only concern is that when does D linked like C++ or dynamic
 selective linked on import that is ONLY really used and not linked ALL
 that is imported....Such thing does not happen in Java because linking is
 done during runtime by Class Loader. I wonder the loader in D for DLL is
 as intelligent.
AIUI, automatic DLL loading is handled by windows, not D (but I think you can also load DLLs manually). Also, D is usually linked statically, not dynamically. I know it's possible for a static linker to eliminate code that's not used, but I don't think OPTLINK (D's linker on windows) currently does it.
Now. That is a feature request to be seriously look into. -- Matthew Ong email: ongbp yahoo.com
May 21 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Matthew Ong" <ongbp yahoo.com> wrote in message 
news:ir7qio$28mn$1 digitalmars.com...
 On 5/20/2011 4:23 AM, Nick Sabalausky wrote:
 "Matthew Ong"<ongbp yahoo.com>  wrote in message
 news:ir3801$84b$1 digitalmars.com...
 As for the real reason it is for:
 That current D layout seem to limit that one file to a single developer.
 Instead of multiple classes by multiple developers within the same 
 module.

 Using the example:
 HashMap&  Unit tested implemented by matthew
 LinkedList&  Unit tested implemented by john
 but the same module is handled by Jonathan for other classes?
That's what version control systems are for. As long as you're using a VCS that isn't terrible (ie, as long as you're not using CVS or Visual SourceSafe), than it's easy for multiple people to edit the same source file.
OK. I read somewhere else about this, I think there is same issue for SubVersion? Someone suggested Hg.
Subversion handles multiple people editing the same file perfectly fine. But Hg probably is better than SVN, overall. I've been a happy SVN user for a long time, but even I'm starting to get won over by Hg. Of course, some people like Git better than Hg (and some people like Hg better than Git).
May 21 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-05-21 at 04:35 -0400, Nick Sabalausky wrote:
[ . . . ]
 Subversion handles multiple people editing the same file perfectly fine. =
But=20
 Hg probably is better than SVN, overall. I've been a happy SVN user for a=
=20
 long time, but even I'm starting to get won over by Hg. Of course, some=
=20
 people like Git better than Hg (and some people like Hg better than Git).
And there is also Bazaar. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 21 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/21/2011 7:16 PM, Russel Winder wrote:
 On Sat, 2011-05-21 at 04:35 -0400, Nick Sabalausky wrote:
 [ . . . ]
 Subversion handles multiple people editing the same file perfectly fine. But
 Hg probably is better than SVN, overall. I've been a happy SVN user for a
 long time, but even I'm starting to get won over by Hg. Of course, some
 people like Git better than Hg (and some people like Hg better than Git).
And there is also Bazaar.
overall this method of D file layout is because of ability to use some sort of Source Control and not because of D cannot compile??? Funny...But going to be hard sell to management level people from the QA side that does not do coding. -- Matthew Ong email: ongbp yahoo.com
May 23 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-23 00:09, Matthew Ong wrote:
 On 5/21/2011 7:16 PM, Russel Winder wrote:
 On Sat, 2011-05-21 at 04:35 -0400, Nick Sabalausky wrote:
 [ . . . ]
 
 Subversion handles multiple people editing the same file perfectly fine.
 But Hg probably is better than SVN, overall. I've been a happy SVN user
 for a long time, but even I'm starting to get won over by Hg. Of
 course, some people like Git better than Hg (and some people like Hg
 better than Git).
And there is also Bazaar.
overall this method of D file layout is because of ability to use some sort of Source Control and not because of D cannot compile??? Funny...But going to be hard sell to management level people from the QA side that does not do coding.
You must work at a fairly odd place if management and the QA people even care whether multiple people edit a file simultaneously. C, C++, and many other languages allow you to put pretty much anything you want in a file and allow you to organize your code however you like. The fact that Java restricts you to a single public class per file is quite abnormal. Sure, if you use a source control system which is poor enough that it won't allow multiple people to edit a file simultaneously, then having a lot of code in a single file could be a problem, but people have worked with horrible source control systems like Visual Source Safe which had such restrictions and still used languages like C and C++ with them. So, even if your SC software sucks, you can use D with it just fine. It's just more pleasant when your SC software doesn't suck. D is organized the way it is because it makes sense. D was designed by C and C++ programmers who found it perfectly normal to split up files however you wanted to. But D improves over C and C++ immensely by using a proper module system rather than textual inclusion. I really don't understand why you're hung up on this idea that you need to only have one person working on a module at a time and think that the fact that the programming language doesn't enforce that you can't have more than one public class per file is a bad thing. Most languages and programming environments just don't work that way. - Jonathan M Davis
May 23 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 2011-05-23 00:09, Matthew Ong wrote:
 On 5/21/2011 7:16 PM, Russel Winder wrote:
 On Sat, 2011-05-21 at 04:35 -0400, Nick Sabalausky wrote:
 [ . . . ]

 Subversion handles multiple people editing the same file perfectly fine.
 But Hg probably is better than SVN, overall. I've been a happy SVN user
 for a long time, but even I'm starting to get won over by Hg. Of
 course, some people like Git better than Hg (and some people like Hg
 better than Git).
And there is also Bazaar.
overall this method of D file layout is because of ability to use some sort of Source Control and not because of D cannot compile??? Funny...But going to be hard sell to management level people from the QA side that does not do coding.
If you really really need it, D supports textual inclusion too, but it is more explicit about it: mixin(import("file.d")); //or maybe you even want to use another extension, so that the compiler does not recognize the files as own modules. So you actually can break up your module into multiple files, if you have no other choice. You would then have one source file that represents the module and just includes all the other modules. But this is a hack and has most problems of textual inclusion. Don't do it. A better way to handle it: You can also just have one module per person and have the top module publicly import all of them. Why do you seem to not want to do this? Timon
May 23 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/23/2011 3:58 PM, Timon Gehr wrote:
 On 2011-05-23 00:09, Matthew Ong wrote:
Thanks everyone that gave some working model to a newbie from Java Space. I found the working file layout model from dwt2 http://hg.dsource.org/projects/dwt2 There is a dwt2\base\src Haha. That is exactly like what I am looking for. Yes. The person made one module to one d file. Super cool. -- Matthew Ong email: ongbp yahoo.com
May 23 2011
parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Mon, May 23, 2011 at 4:39 AM, Matthew Ong <ongbp yahoo.com> wrote:

 On 5/23/2011 3:58 PM, Timon Gehr wrote:

 On 2011-05-23 00:09, Matthew Ong wrote:
Thanks everyone that gave some working model to a newbie from Java Space. I found the working file layout model from dwt2 http://hg.dsource.org/projects/dwt2 There is a dwt2\base\src Haha. That is exactly like what I am looking for. Yes. The person made one module to one d file. Super cool.
Yes, but DWT is also an almost direct port of a Java project (you'll also find a port of quite a bit of the Java standard library in there), so you really can't use it as an example to support any sort of D style. The authors did what made sense in a library that wasn't designed for D.
May 23 2011