Why the compiler dosen't enforce correct module declarations?

[gareis]

== Quote from Bruno Medeiros (brunodomedeiros+spam at com.gmail)'s article
> Sean Kelly wrote:
> > Ary Manzana wrote:
> >>
> >> Shouldn't the compiler say "Wait, you are saying that module one is in
> >> file main.d, module two is in other.d and module lala.la is in
> >> dir/some_other.d, this isn't quite well"?
> >
> > I've decided that this is actually a good thing.  It allows large
> > modules to be split across multiple files and for different
> > implementation files to be chosen at compile time when using the
> > header/source model.  It's also the only way I've found to compile the
> > implementation of "object.d" for Tango.  Actually naming it "object.d"
> > caused all sorts of problems.
> >
> >
> > Sean
> But:
> A) "It allows large modules to be split across multiple files"
> What do you mean? Splitting a large module into multiple files implies
> putting each new file in a different module. What does that have to do
> with allowing module-file name mismatches?

The first part is mostly naming convention. Though if you can't possibly imagine
using one file without having the exact source of another file, they should be
one module. You could combine the files, but that tends to work poorly after a
while.

Still, I'd use imports most of the time, if it were possible.

For the second part, Mr. Kelly gave an example: his object module couldn't
appear in object.d without causing issues.

> B) "and for different implementation files to be chosen at compile time
> when using the header/source model."
> And why is that a good thing? If I use conditional compilation and
> define conditional properties at compile time I achieve the same effect.

You can wrap your entire file in version statements, but then it's difficult to
work with. If you have multiple people working on the functions for different
versions, you might get conflicts with cvs / subversion / what-have-you
(especially with coding style and editor issues). And IDEs might barf on entire
functions wrapped in version statements and appearing multiple times.

You could wrap all the import statements in version statements, but that's ugly
and doesn't scale that well. Modules that aren't platform-specific or
feature-specific will end up having to pay attention to platforms and features.

You could have a module that just has a bunch of statements like:
---
version (Windows) import foo.windows;
version (Linux) {
   version (Bigendian) {
      import foo.linux_bigendian;
   } else {
      import foo.linux_little_endian;
   }
   version (UsingSSL) import foo.linux_ssl;
}
---

That's also annoying. And contrived.

Still, if you're using makefiles and autotools, conditional compilation of files
is the easiest way to go. You can compile each file into a separate object file
for faster recompilation in the face of changes, and you don't have any issues
with, for instance, foo.windows panicking because it can't use Windows functions
on Linux.

I'm not sure whether dsss allows for this sort of thing -- a source file that
will not be used on one system and will not compile on it, but will be used on
another system and compile on it.