Jarrett Billingsley wrote:
On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun<yigal...@gmail.com> wrote:
I agree with the above but there is still a small issue here:
A module is a single file and when you have several large classes that are
tightly coupled you can get a very big file with thousands of lines. what if
i want to put each class in its own file?
besides, the notion of a module is somewhat redundant - it's functionally a
static struct.
this is related to D's compilation model which is copied from C/C++ and it
seems to me that this model is outdated. C#'s model of assemblies and
metadata seems more capable. for instance there's no need for header files,
that info is stored in the metadata of the assembly.
Preciiiisely. I've been toying with the concept of a compiler which
doesn't actually emit object files until it has to link its code into
some form of executable. Instead it produces these sort of
platform-independent internal representation files, which can contain
all the metadata and symbol information needed. They can be as small
as a single module or as large as an entire multi-level package. It
sounds a lot like the model C# has adopted.
I also think that source code organization should be orthogonal to the
organization of the deployment executables (assemblies in .net)
something simillar to namespaces in C#.
other useful metadata to include in those files is the documantation and
versioning info.
