On Sat, 2004-08-07 at 04:04, Peter Moulder wrote:
On Sat, Aug 07, 2004 at 02:08:33AM -0400, MenTaLguY wrote: 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.
Have you measured the compile-time impact of having Traits::TreeIterator<SPObject *> in sp-object.h?
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.
They certainly do serve a documentation role as well.
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.
That may depend on how many traits classes are typically needed at once, also. The number is going to increase, since there are some other distinctions/abstractions that I think are important.
One in particular is equality... I'm seriously considering adding a Traits::Eq template which draws a distinction between "equal" and "equivalent" similar to Scheme's equal? versus eqv?; I imagine most of the generic algorithms will end up using it.
If every generic algorithm has a shopping list of traits headers required (some of which are necessarily implementation details rather than obvious parts of its interface), coming up with the required headers could get very obnoxious quickly (it's already a little obnoxious with nr-matrix headers).
I think it is pretty important that the generic algorithms "just work" (and are efficient, but that is an unrelated issue), otherwise people will simply not use them.
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.
Yes, that's one I've been wanting to do for a while, although I actually think sp-desktop-widget belongs in widgets/, if it is possible.
-mental