Library standardization (automatic generation of .di files is unsafe)

[Bruno Medeiros]

Walter Bright wrote:
> Edward Diener wrote:
>> 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.
> 
> But it is quite possible to separate D modules into "headers" and 
> "implementations", if desired. Phobos does this for the gc, for example.
> It can also be done automatically by generating .di files.


Walter, seriously now, have you read e-t172's scenario with attention?
(news://news.digitalmars.com:119/fuhq4t$26dg$1@digitalmars.com)

In what he describes, the automatic generation of .di files is not safe, 
because some pieces of "implementation" get stuck in the .di files (even 
more in a indeterministic way to the programmer). Because of that, a 
change in implementation of a shared library, without change in the 
interface, may nonetheless require the users of the library to recompile 
their code.
Now if you recall, that goes precisely against the purpose of a shared 
library (being able to update the shared library alone, without 
recompiling the whole program).
So the creators of shared libraries, in order to create a proper 
library, have to search through the exposed .di files and look for 
places where "implementation details" are exposed (and then either 
removed them, or check if they have changed since previous versions). 
That's tedious, unnecessary, and error-prone unless fully automated.

(I wonder why this issue hasn't cropped up before. The problem may occur 
only in very rare circumstances, but still, it's there.)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D