Proposed improvements to the separate compilation model

Rob T alanb at ucora.com
Sun Mar 3 22:06:06 PST 2013


On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu 
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).
>
> 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

One of the main selling points of the module system is to prevent 
exactly what you are proposing, so I think there must be a better 
solution.

The biggest disappointment I have with modules, is that you 
cannot define an interface inside of them, and must instead 
resort to a .di file.

Manually maintaining a .di file is a bad idea for what should be 
obvious reasons, and the auto generation of the .di is a failure 
because you cannot tell the compiler how to generate the .di file 
from inside the module.

For a solution, what I'd like to see is manual control over what 
will go into an automatically generated .di placed directly 
inside the D module.

For example, allow the programmer to specify the separation of 
interface from implementation directly inside the module through 
an improvement to how modules are defined, that is to say allow 
the programmer to specify what is a part of the interface and 
what is a part of the implementation directly inside the module. 
The compiler can then auto generate the necessary .di interface 
files from that information, the obvious benefit being that 
you'll get interface and implementation separation without the 
separation of where the control point is, eg it's all done inside 
the module where it should be done and nowhere else, and do it 
without a duplication of definitions. This can possibly be done 
without duplication through the attribute system.

There should be a way for the compiler to determine if previously 
auto generated interface files are the same or differ to prevent 
overwriting and forcing unnecessary recompilation. If the .di 
files are stored in specific locations away from wher the 
compiler is dumping them, then you could add an "include" switch 
to tell the compiler where to look for previously generated .di 
and compare them.

Sure it's a bit of effort to implement, but it seems like a far 
more useful solution that is safe, scalable, and easy to maintain.

--rt

PS: While we're on the topic of interfaces (or lack thereof), 
another problem point I have with D is that while you can define 
an interface for classes, you cannot do the same thing with 
structs. I don't understand why structs cannot have interfaces.


More information about the Digitalmars-d mailing list