How to break module into multiple file.

[Adam Burton]

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
> allowed to have one public class in them is something tha only C# and Java
> 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
> completely normal and common. It just doesn't match Java and C#.
> 
> - Jonathan M Davis
Actually C# doesn't have that limitation. C# uses namespace {} so you can 
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