On Wed, 21 Oct 2009 18:16:48 -0400, AJ <[email protected]> wrote:
"Steven Schveighoffer" <[email protected]> wrote in message
news:[email protected]...
On Wed, 21 Oct 2009 17:59:52 -0400, AJ <[email protected]> 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
