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