Library standardization

Hans W. Uhlig huhlig at gmail.com
Sat Apr 19 22:43:57 PDT 2008


Edward Diener wrote:
> 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.

Perhaps this is where we need to have some form of Library tag for a 
module. I.E. This module will become a library with a "fixed" api and 
should be treated thusly. Generate an API file full of meta data and 
allow the compiler to compare "new versions" against the API. this can 
gain two advantages. A) the compiler lets the programmer knows when he 
breaks API (syntactically). B) all interface functions are defined in 
the API file so all thats necessary is said API file. I am unsure if .di 
files can accommodate this.

Oh, and a note about .di files, why not just have them run through a 
pretty printer?



More information about the Digitalmars-d mailing list