Proposed improvements to the separate compilation model

Vladimir Panteleev vladimir at thecybershadow.net
Tue Mar 5 12:40:40 PST 2013


On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
> Perhaps then, what I think is the most significant point of all 
> is being missed. I can see a very clear reason why in terms of 
> source code, the interface and implementation must not be be 
> separated. Automated .di generation is a means to solve the 
> need for separation when distributing libraries, whoever what 
> goes in the .di should not be considered as your "source code" 
> because it should be auto generated from the source (eg your .o 
> files are not source code in the same way). I

I agree with Rob T on this point. Being free from the burden of 
maintaining an interface file was one of the selling points of D 
vs. C++ for me - repeating the same changes over and over in the 
.cpp and .h file was a pointless distraction and strain on my 
productivity, especially during prototyping.

Even though the feature, if introduced, will be optional, sooner 
or later it will end up in a library (likely, written by a 
misguided programmer coming from C++), and I will have to debug 
it - so I don't consider "don't use it if you don't like it" a 
real argument.

Also, I don't think that we should consider that a class 
declaration is the same thing as the class interface - for the 
simple reason that a class declaration must also contain private 
fields and methods. Having to recompile half of my program just 
because of a signature change in a class's private method makes 
no sense, and is the reason why hacks like PImpl emerged.


More information about the Digitalmars-d mailing list