"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message news:op.u15929x0eav...@localhost.localdomain... > On Wed, 21 Oct 2009 18:16:48 -0400, AJ <a...@nospam.net> wrote: > >> >> "Steven Schveighoffer" <schvei...@yahoo.com> wrote in message >> news:op.u157hfkveav...@localhost.localdomain... >>> On Wed, 21 Oct 2009 17:59:52 -0400, AJ <a...@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).
I wouldn't use the term "interface" in this context for it has other meaning in OO. > 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. You lose the ability to use, say a class declaration, as the specification (at least without a sophisitcated, code-folding/code-formatting IDE).