On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is managed
manually and separately from the implementation file (.d).
I have mixed feelings on this proposal.
On one hand, one of the best parts of D over C++ is it's module system.
No more #ifdef __thisfile_included crap, and implementations just sit
right where they are defined. My concern with such an improvement is that
it would encourage people (especially C++ coders) to unnecessarily split
their implementation from the definition. I think there have been at
least 2 or 3 people ask how to do this in D. I really like that
implementation and definition are all in one file, and cannot be out of
sync (a common problem with C++). Already di files allow for these
problems to creep back in, but I understand it's a necessary evil.
On the other hand, the duplication of definitions and functions for
inlining when you do want to use .di files is a real problem, and this
would seem to address it. And as you point out, it doesn't eliminate the
existing solution.
Plus, D does not suffer from multiple-personality syndrome like C++ can.
For example, including a file more than once with different macro
definitions to alter the impact of the include file.
As a criticism though, I don't really like this:
module std.foo;
import std.foo; // huh?
I know we don't want to add too much to the syntax, but can we make that
line a bit more descriptive? and also less redundant? Suggestion:
module std.foo;
import interface; // imports the .di file that corresponds to std.foo.
I know that's keyword abuse, but it's kind of accurate ;)
-Steve
