Proposed improvements to the separate compilation model
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Jul 22 15:06:19 PDT 2011
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).
After discussing a few ideas with Walter, the following language
improvement came about. Consider a very simple scenario in which we have
files a.d, a.di, and client.d, all situated in the same directory, with
the following contents:
// a.di
class A { private int x; int foo(); }
// a.d
import a;
int A.foo() { return x + 1; }
// client.d
import a;
void main() { (new A).foo(); }
To compile:
dmd -c a.d
dmd -c client.d
dmd client.o a.o
Currently, in order for a program with separately-implemented methods to
work properly, there must be TWO different files for the same class, and
the .di file and the .d file MUST specify the same exact field layout.
Ironically, the .d file is forbidden from including the .di file, which
makes any checks and balances impossible. Any change in the layout (e.g.
swapping, inserting, or removing fields) is undetectable and has
undefined behavior.
I see this as a source of problems going forward, and I propose the
following changes to the language:
1. The compiler shall accept method definitions outside a class.
2. A method cannot be implemented unless it was declared with the same
signature in the class definition.
Walter is reluctantly on board with a change in this direction, with the
note that he'd just recommend interfaces for this kind of separation. My
stance in this matter is that we shouldn't constrain without necessity
the ability of programmers to organize the physical design of their
large projects.
Please discuss here. I should mention that Walter has his hands too full
to embark on this, so implementation should be approached by one of our
other dmd contributors (after of course there's a shared view on the
design).
Andrei
More information about the Digitalmars-d
mailing list