Header files (Re: A little review of kdecore & kdeui)

[Cornelius Schumacher]

On Saturday 08 April 2006 00:42, Harri Porten wrote:
>
> An example of what I meant by runtime errors: I'm using a container that
> somehow gets corrupted during execution of my program. Let's say I'm using
> QList and being a Trolltech deciple I'm using the <QList> header. Now,
> where do I head looking for the exact definition of the class
> (documentation does never provide the full truth)? The QList header file,
> of course. But opening that file in my editor I see that I was wrong and
> get redirected somewhere else: qlist.h. Nothing that can't be solved by an
> editor macro but why the detour?

The reason for the include aliases is obvious: You can always use the class 
name for including headers and never have to look up header file names. 
That's obviously a pretty big advantage.

As including headers for classes you use is a much more common task than 
reading header files I think it's pretty clear where to spend the effort, 
especially as the include aliases are only an additional feature and don't 
change anything in the actual header files.

> Same for compile error: if I spot an error when using KBar my first
> reaction is look in the documented header for it.

This seems to be an issue of the documentation then. If you look for the 
documented header and it doesn't refer to the actual header file, the 
documentation should probably add a link to the header file. I would welcome 
such an improvement.

> I was resisting to touch the lower vs camel case debate here ;) But
> independant of that I see the existance of two headers (KFoo and kfoo.h)
> responsible for the same thing (defining a class) to only cause confusion.
> Header file redundancy is at least as bad as code duplication ;)

As the class name header aliases are no header files but only links to the 
real files I don't think your argument holds here.

-- 
Cornelius Schumacher <schumacher at kde.org>