On Sat, Aug 07, 2004 at 02:08:33AM -0400, MenTaLguY wrote:
One of Peter's recent commits (moving Traits::TreeIterator<SPObject *> into a separate header file) started me thinking more about what should go in a separate header file and what shouldn't.
In _general_, I think "one class, one header" is the right approach, but some auxiliary classes (for example, traits specializations) have a more intimate relationship than most classes, and don't introduce any dependencies of their own.
Any thoughts on where a good place to draw the line might be, in general?
Apart from the class-per-file guideline, I was motivated by reducing compile times: sp-object.h is #included by almost everything (being a base class of all shapes), whereas sp-object-tree-iterator.h is currently #included by exactly one file: sp-object.cpp.
Of course our primary concern should be developer time. Reducing compile times does improve developer efficiency, but that should be weighed against other time costs such as finding what header files need to be included to get the compile to work, or possibly the cost of wrongly assuming that it won't work when the compile fails.
Comments on intimacy: On one hand, giving facts about a type might well be seen as belonging with the definition of that type. On the other, traits classes might rather be seen as showing ways in which the type can be used.
If the programmer knows that to use a Foo as a BarTrait requires that one #include "Foo-BarTrait.h" (or other regular pattern used consistently throughout inkscape), then I think it's fine.
Looking at other instances of splitting things into a separate header file:
I'm confident with the decision to split sp-desktop-widget.h from desktop.h. E.g. because it leaves the latter with no gtk dependency.
A much more questionable case is splitting nr-matrix.h into many files. See the end of that file for comments on this.
pjrm.