Proposed improvements to the separate compilation model

Dicebot m.strashun at gmail.com
Tue Mar 5 13:24:14 PST 2013


On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev 
wrote:
> 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.

And what issues may arise exactly? So far all stuff mentioned is 
C-approach specific, everyone is speaking about possible problems 
without specific example.


More information about the Digitalmars-d mailing list