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