Re: [boost] [GTL] redesign checked into sandbox

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-10 06:57:04

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