On Sun, 2004-08-08 at 04:52, Peter Moulder wrote:
On Sun, Aug 08, 2004 at 02:31:16AM -0400, MenTaLguY wrote:
Have you measured the compile-time impact of having Traits::TreeIterator<SPObject *> in sp-object.h?
For developers, recompilation time is most significant. Separate headers means that changes to what might go in a separate header cause only sp-object.o to be rebuilt rather than most of inkscape.
A traits specialization is not going to change unless the primary class does (and seldom even then), and the addition of new specializations is a fairly rare occurrence.
They certainly do serve a documentation role as well.
For the most part better served by a comment.
Comments also cause recompilation. Do they belong in a separate header?
I guess that's actually a serious question. Recompilation times have discouraged me from going back and commenting sometimes when I felt lazy. I believe Doxygen permits documentation in separate headers or in the .cpp file.
On the other hand, that may mean fewer people read the comments.
However, an advantage of code over comment is that code is checked by the compiler.
Since templates are lazily evaluated, traits specializations are not well-checked by the compiler, beyond their existence or non-existence.
Actually, as a result, if the primary class is not updated without having its traits specializations updated it may not be apparent for a while. So that might be an argument for keeping them next to the primary class, where they will be visible.
("oh, hey, this traits specialization uses this method I just changed the signature of...")
I guess there's a similar issue with comments as well, though obviously the comments getting out of sync will not directly impact the correctness of the code.
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.
If we decide to put each traits class in a separate header for the moment, then we can later add `#include the-separate-header' to whatever places we think appropriate wenn it becomes appropriate to do so.
That's true. I guess the only real issues are human rather than technical.
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.
The STL approach is to allow the user to specify a comparison predicate. We should use that approach in preference to different equality traits if we can.
Well, the motivation is that in some cases more than one notion of equality is required in the same place (c.f. comments in longest_common_suffix).
But yes, the predicates ought to be configurable. Eq would still be desirable for specifying default predicates (STL also uses traits classes for its defaults).
-mental