Yigal Chripun wrote:
> *but*, I do think that splitting one file that got too big over time or uniting a bunch of small files into one should be possible.

This would be especially good for us. D is mainly developed by individuals, and there projects tend to grow organically -- as opposed to the software industry that uses UML and other modeling tools, where the entire gamut of classes is known before coding starts.

So, yes, it should be possible to reorganise code between files without having to touch the code that uses them.

Georg Wrede wrote:
> Yigal Chripun wrote:
>> *but*, I do think that splitting one file that got too big over time or uniting a bunch of small files into one should be possible.
> 
> This would be especially good for us. D is mainly developed by individuals, and there projects tend to grow organically -- as opposed to the software industry that uses UML and other modeling tools, where the entire gamut of classes is known before coding starts.
> 
> So, yes, it should be possible to reorganise code between files without having to touch the code that uses them.

It *is* possible, by use of public imports.

Are you splitting one file into many? Public import the other modules.

Are you merging many files into one? Leave the other files with just a public import of the merged file.

Christopher Wright wrote:
> Georg Wrede wrote:
>> Yigal Chripun wrote:
>>> *but*, I do think that splitting one file that got too big over time or uniting a bunch of small files into one should be possible.
>>
>> This would be especially good for us. D is mainly developed by individuals, and there projects tend to grow organically -- as opposed to the software industry that uses UML and other modeling tools, where the entire gamut of classes is known before coding starts.
>>
>> So, yes, it should be possible to reorganise code between files without having to touch the code that uses them.
> 
> It *is* possible, by use of public imports.
> 
> Are you splitting one file into many? Public import the other modules.
> 
> Are you merging many files into one? Leave the other files with just a public import of the merged file.

Nice story. In reality you face all kinds of problems: like circular dependency bugs, public/private/package are not fine enough (friend modules or a fixed package attribute would be nice), and you still can't split the implementation of a class across several files. But yes, I guess I could implement a CTFE driven preprocessor using import(), which would solve all problems. And then you switch to another language, because all the bugs and kludges just isn't it worth.

grauzone wrote:
> Christopher Wright wrote:
>> It *is* possible, by use of public imports.
>>
>> Are you splitting one file into many? Public import the other modules.
>>
>> Are you merging many files into one? Leave the other files with just a public import of the merged file.
> 
> Nice story. In reality you face all kinds of problems: like circular dependency bugs, public/private/package are not fine enough (friend modules or a fixed package attribute would be nice), and you still can't split the implementation of a class across several files. But yes, I guess I could implement a CTFE driven preprocessor using import(), which would solve all problems. And then you switch to another language, because all the bugs and kludges just isn't it worth.

Then: it *should* be possible, but compiler bugs sometimes prevent it, and there is an old issue with circular imports with static constructors that you will often run into, and you might want fine-grained access control that you won't always have if you split a file into multiple subpackages as well as multiple files.

However, I would like to see use cases for putting one module in multiple files, and for putting one class in multiple files.

The only use case that springs to mind for one class in several files is when part of the class is generated by a tool, though you can handle that with inheritance instead.

I see no use case for having one module in multiple files, though -- the only benefit would be private access to things defined in other files. I've never been big on making stuff private, though.

On Wed, 06 May 2009 02:36:21 +0400, Christopher Wright <dhasenan@gmail.com> wrote:

> I see no use case for having one module in multiple files, though -- the only benefit would be private access to things defined in other files. I've never been big on making stuff private, though.

There is a use-case. Imagine you want to define a Thread class. It has a common interface, but its implementation is heavily platform-specific, and sometimes involves manual assembly.

Putting all the implementation into one file would make it very big, source code a complete mess and following it would be very hard. Instead, you may wish to define its interface in Thread.d(i), yet put its implementation in multiple files: Thread_win32.d, Thread_posix.d etc.

I use the same trick to unify socket API. For some reason, every platform introduce small API changes. Some call a function closesocket, others - socketclose etc. That's why I have SocketApi.di which contains the following declarations:

   SocketDescriptor socketCreate(SocketAddressFamily addressFamily, SocketType type, SocketProtocol protocol);
   SocketDescriptor socketAccept(SocketDescriptor listenSd);
   bool socketClose(SocketDescriptor sd);

   bool socketSetupListen(SocketDescriptor sd, uint maxQueue = 0);
   bool socketSetupNonBlocking(SocketDescriptor sd, bool nonBlocking);
   ....

Each platform implements these functions a bit differently. Their implementation is stored in SocketApi_win32.d, SocketApi_linux.d etc. And, yes, all of them have "module SocketApi;" on top of the file.

I don't want to split a big class into several smaller classes, just to be able to distribute it across several source files.

Actually, the D module system makes me to implement several "aspects" of something as several classes. Just to be able to put the implementation into several files. Of course, you could argue splitting it into smaller classes is cleaner (and forces you to do a cleaner design etc.), but in reality, this just causes code bloat. You need additional code to interface with the other classes, ensure encapsulation, etc. But putting it into a single class is so much simpler, and in the end KISS > complexity.

Oh, how much simpler was programming, when you'd just define global variables and global functions in several source files? At least that's what I think when I look at such "simple" code. (My opinion usually changes if I have to fix bugs in it.)

Open types could help to make putting different aspects of a class into different files. You know, just adding new member variables or virtual functions to a class from "outside". Oh, and you can do this for free in dynamic languages. I think they call it "monkey patching", but it has the following disadvantage: all the added members live all in the same namespace, regardless of what source modules did add them to the object.

By the way, Aspect oriented programming languages won't solve this. Usually they are clusterfucks which just add complexity on top of already complex languages. A good example is AspectJ.

Denis Koroskin wrote:
> On Wed, 06 May 2009 02:36:21 +0400, Christopher Wright <dhasenan@gmail.com> wrote:
> 
>> I see no use case for having one module in multiple files, though -- the only benefit would be private access to things defined in other files. I've never been big on making stuff private, though.
> 
> There is a use-case. Imagine you want to define a Thread class. It has a common interface, but its implementation is heavily platform-specific, and sometimes involves manual assembly.
> 
> Putting all the implementation into one file would make it very big, source code a complete mess and following it would be very hard. Instead, you may wish to define its interface in Thread.d(i), yet put its implementation in multiple files: Thread_win32.d, Thread_posix.d etc.

If that's the main concern, public import works fine, along with, optionally, an interface.

However, if there's a lot of shared code as well as a lot of platform-specific code, that's not very fun at all. Your options are to define a base class with the common code (yech) or munge all the platform-specific code together.

On Mon, 04 May 2009 18:23:50 -0700, Robert Fraser wrote:

> Daniel Keep wrote:
>>> Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.
>> 
>> Oh what rubbish.  You can use whatever case you please.
> 
> On Windows (actually NTFS, I think), you can't two packages/modules that differ only in case. But if you have namespaces "XML", "Xml" and "xml", you probably have some bigger design issues.

You can actually, just Windows can not distinguish between the two if you do. The point was that you are not restricted to only using lowercase, it can be uppercase. And in the case of windows, it can't even tell the difference anyway (dmd might enforce it).