Re: Header cleanliness [was: removing the 'makeinstall'-->'makeall' dependency]

[David Ayers]

Alexander Malmberg wrote:

> * A header must be self-contained. If it needs any definition from
> another header, it must include it itself. To catch violations of this
> (which are very annoying, and I know from experience that it's easy to
> just include some extra headers in your app/tool until it works and then
> forget about it instead of fixing it), each .m file should include its
> corresponding header before doing anything else.
>
> * A header should include as few other headers as possible. Use @class
> instead. This speeds up compilation, doesn't pollute the user's
> namespace, and doesn't break things when a header suddenly stops
> including some other header (I've been bitten by this as well; better to
> sort it all out at once).
>
> Comments welcome.
>
>  
With the exception of GSWeb (in which things are currenlty more 
complicated) I would be all for both of these suggestions.

I really don't want to get off the topic too much but... :-)
Another thing I keep wondering about, is whether libraries and 
frameworks (should/must) include thier own project headers with a 
prefix. i.e. why NSArray.m includes:

#include <Foundation/NSArray.h>
instead of
#include "NSArray.h"

and why NSArray.h includes:
#include <Foundation/NSRange.h>
instead of
#include "NSRange.h"

I know gnustep make changes the search order so that the source headers 
are found before the installed headers but if a header is ever removed 
from the source, make will still pick up the installed header.  On the 
other hand, the second scheme also works well and I have a feeling that 
it is more correct.  But maybe I'm missing something, enlighten me 
please :-)

Cheers,
Dave