No header files?

[AJ]

"BCS" <none at anon.com> wrote in message 
news:a6268ffbae78cc207990f9b394 at news.digitalmars.com...
> Hello aJ,
>
>> "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.
>
> As it happens, .di files are just .d files that by convention only contain 
> the interface. You can declare a class in a .d file and not give bodies 
> for its methods and you won't get errors till link time, just like in C.
>
>> 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).
>
> I'm not sure what use you are seeing for them.

The 2 that I gave were:

   1. Serves as a "blueprint" (or skeleton) for further development.
   2. Serves as "documentation" for usage or for evaluation-for-purpose 
(suitability).

(1) is "working at a higher level (designing vs. implenting) and perhaps 
even separating much of the design work from the implementation work (i.e., 
separate individuals or teams working on one or the other). (2) eliminates 
the need for secondary documentation (for well-designed code). I think of 
secondary documentation as the detailed description of how something works. 
Prior to consulting such, I'd want to know "what" something is, and 
something like a class declaration gives me that information immediately, 
without reading paragraphs of text. For example, you can describe "car" to 
me, but it would be much easier to just show me one.

> As far as documentation goes, In the cases where I don't care about the 
> implementation, I'd rather see some kind of extracted, generated 
> documentation rather than a header file.

Class Shape
{
    void Draw();
}

What more do you need to know usually?

> The only argument I see for a header/implementation split is if you need 
> to put part of a class in one file and part in another and I think that is 
> a very weak case.