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