No header files?

[Steven Schveighoffer]

On Wed, 21 Oct 2009 18:16:48 -0400, AJ <aj at nospam.net> wrote:

>
> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
> news:op.u157hfkveav7ka at localhost.localdomain...
>> On Wed, 21 Oct 2009 17:59:52 -0400, AJ <aj at nospam.net> wrote:
>>
>>> Since D has no header files, how does one create "a library" that  
>>> another
>>> developer can use without exposing the implementation?
>>
>> try dmd -H.
>>
>> .di files are D header files, basically used for the reason you specify.
>
> OK, so header files can be generated. The thing is though, when I am
> designing at the code level, I start with the declarations (such as class
> data members and methods) and do the implementation (or one can hand it  
> off
> to someone else) afterwards. That serves as the "blue print" for further
> development and remains as first level of documentation as well. Working
> with just "implementation files" seems to be putting the cart before the
> horse. While eliminating something unnecessary is something to strive  
> for, I
> don't think header files are unnecessary in the development process  
> (i.e., I
> don't think that relegating them to just the situation given with my OP  
> is
> good, exactly for the reasons of usefullness I gave).

Separating interface from implementation is good -- but not if you have to  
repeat the interface (as you do with C++ or C).  What happens (and being a  
long-time C++ developer, I've had my fair share of experience with it) is  
that the interface gets out of sync with the implementation, so weird shit  
happens.

I even think d's "editable" interface files are suspect.  They can be out  
of sync with the object files, and then you have the same problem.  The  
best model by far is Java and C# where the object files *are* the  
interface files.  Then you only have to worry about documentation being  
out of sync.  But at least your programs don't crash randomly for no  
reason because the docs are invalid.

What I would suggest is creating stub functions via {} and then when you  
go back to fill in the interface, fill in the {} area.  You get the same  
effect.

-Steve