Bruno wrote:
1. Prefer metafunctions in the point concepts requirements over traits classes, or I'm afraid the traits will get huge.
If the traits are huge the abstraction is being made in the wrong place. A good abstraction is a min-cut in a graph of dependencies. A huge number of metafunctions seems equally bad to me. Instead the goal should be to minimize the number of traits/metafunctions required to be understood/specialize by the user.
I know the principle of avoiding blob traits, as exposed in Abrahams and Gurtovoy's book. But I think it doesn't apply here just because the traits in question is *way* short. A type, a value, an accessor. And most algorithms need all of them. Does it really make sense to scatter them into several metafunctions??
Well, I wrote / suggested that because I have in mind a very generic set of concepts associated with points that would be compatible with libraries like CGAL. I am worried that the traits will explode becuase there are so many uses for a point class that have subtly different requirements. The number of associated types etc. in the CGAL Kernel seems to indicate that in a sturdy geometry library that might be the case. eg, it looks a little bit like a point concept will require a 'space' concept that will end up involving tons of associated types for compatible geometric primatives (as in the CGAL Kernel).
2. Put your concept mapping functions in a namespace rather than a class (do it like like Fusion does). Namespaces seem to provide a lot more flexibility, and the syntax is a LOT cleaner.
I am considering the implications of your suggestion. It could be that it can be made to work, but I'm not clear on how overloading functions in a namespace is preferable to specializing a struct. It seems that it is more prone to compiler errors related to overloading ambiguity caused by bad user code and unfortunate combinations of user code. With the traits there is no chance for ambiguity.
I agree with Luke on this point, I'm afraid about nightmares that overloading ambiguities could bring to the user. However, I will consider doing a few tests to see the actual consequences of what you propose.
I am not talking about requiring user code to depend on ADL, I mean make a special 'adapted' namespace like fusion does. I foresee less problems with ::point::adapted::at_c<0>(point); than I do with point_traits<MyPoint>::template at_c<0>(point) This involves 2 parts: 1. _if_ the traits get to be huge, it is possible to split namespaces accross header files. 2. The annoying 'template' keyword can be a source of problems, since it has been my experience that some compilers require it and others dont. I am also concerned about the 'typename' keyword (for the same reason). Some traits will also probably apply to multiple concepts, and since you can't partially implement a traits class, you will have to mix them by inheritance (I think) if you want to share some traits. Then you end up with an issue about dependant names inherited from template base classes that happens on g++ and not microsoft compilers.
3. Provide separate headers for each metafunction. This allows users to fucus on metafunctions that matter.
I am doing this already, though there is only one metafunction that matters right now; the one that maps the user type to its related concept.
Same remark as above: one metafunction and one separate header of each of the 3 properties needed, I wonder if it's not a bit overkill...
I have only seen what look like the very beginnings of the development of these concepts, and I made those comments anticipating an explosion of traits.
From earlier disccusion I really think that compatibility with CGAL will be important for these concepts, and I worry when I look at the number of typedefs required by the CGAL Kernel concept. It is a bit bigger than two or three typedefs.
4. Make all requirements explicit in the concept class. This way I can look at the concept code and see what they are.
Aren't the requirements explicit enough in the concept class I've shown? If not, could you be more precise on what you'd like to see more clearly specified?
Bruno
I was worried because somebody was talking about using the traits class to add additional constraints. In your posted code, I dont see the actual definition of a traits class (I see a 'dimension_checker', and I see a point_traits template being used...) -- John