Library standardization

[Edward Diener]

Sean Kelly wrote:
> == Quote from Janice Caron (caron800 at googlemail.com)'s article
>> On 19/04/2008, Sean Kelly <sean at invisibleduck.org> wrote:
>>>  Changing a source file should require the application to be re-linked.
>> [but not recompiled]
>>>  As someone who has worked on programs that can take half a day to build,
>>>  I would throw a fit if every source change required a full rebuild of code that
>>>  simply includes a header related to this source.
>> So you want the ability to import a module, but not have to rebuild
>> dependent files if that module changes?
>> Good luck with that one.
> 
> Apparently you've never used C/C++.  I apologize or the misunderstanding.

I think there is a miscommunication here.

In C++ terms, if a source file changes in such a way as to change the 
declaration for other dependent code which needs to use that 
declaration, then obviously the other dependent code needs to be 
recompiled just to pick up the new declaration. Otherwise there should 
be no need to recompile dependent code if just the definition and its 
functionality changes.

In D one of the negatives of having everything in a single .d file is 
that there is no separation between the declaration and the definition 
since the definition defines the declaration. Unfortunately this appears 
to lead to the fact that if the .d file changes then any other .d file 
which imports the original one ( has a dependency on the original one ) 
needs to be recompiled.

In having a single files where the definition is the declaration, as in 
D as well as Java, C#, and Python, you win some and you lose some. In 
the case of rebuilding code, you definite lose some as opposed to C++'s 
dual header/source file paradigm. However in a dynamically typed, 
interpreted language such as Python, there is no compilation stage so 
winning or losing is not an issue for this case.