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

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-10 01:32:55

> Luke wrote:
> >> You do raise a valid point, there is currently no concept checking 
> >> included in the design and implementation I checked into 
> the sandbox.
> >> Is it valid to call something a concept if there is no concept
> checking?
> 
> Bruno wrote:
> >Yes it is. 

Oh, maybe my point of view was too narrow then :)  In _this_ context I
thought checking was a requirement, otherwise why make a class? without
checking it is just documentation right?
 

> >But in my opinion, showing up a concept class has the 
> >advantage of clearly communicating the intention to the community in 
> >order to validate / invalidate the design. Moreover, since two 
> >geometry-related libraries are currently being developed for Boost 
> >(even if they don't do the same things) I think comparing 
> the concepts 
> >used would allow us to see exactly what are the convergences / 
> >divergences, and see what can or cannot be done to make them 
> as close 
> >as possible. A certain level of consistency between those libraries 
> >would surely be appreciated.
> 

So what I am interested in is making those assumptions explicit, and
providing the tools to check that my _own_ private code is going to work
with whatever makes it into boost. That is why I say I care more about
concepts (meaning checkable concepts & archetypes) than I do about the
algorithms in a boost geometry library.

> It actually forwards everything to the point_traits class in 
> order to check that everything needed is accessible through 
> point traits for the point type begin checked. Since you rely 
> on point traits too, I suppose you would have the same approach?
> 

My _personal_ opinion is that I prefer type generators or metafunctions
to monolithic traits classes.  When I looked at the CGAL kernel types
(although it's been a while since I did)  I realized how many typedefs
etc. can pile up in a traits class. Frankly I think that makes traits
harder to understand or work with. In the case of CGAL I did not know
what a lot of the stuff meant because it dealt with aspects of geometry
I was not dealing with at the time. 

Since I think any boost geometry library should be CGAL compatible, I
would vote that the boost approach should be to decompose point traits
into a bunch of metafunctions in their own tiny header files. You only
include the header files with metafunction that apply to your task.

For my two cents I reccomend:

1. Prefer metafunctions in the point concepts requirements 
   over traits classes, or I'm afraid the traits will get huge.
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.
3. Provide separate headers for each metafunction.
   This allows users to fucus on metafunctions that matter.
4. Make all requirements explicit in the concept class. This
   way I can look at the concept code and see what they are.
   

> If you don't want to do that right now because you're afraid 
> about the profusion of concept checking macros in your code, 
> I think that putting a BOOST_CONCEPT_ASSERT in the 
> point_traits class is sufficient with this approach, since 
> any access to a point should be performed only through this 
> class. This way, you don't have to rewrite the check in every 
> algorithm, and the only job you have to do is writing the 
> concept class. However, as I'm not used yet with the BCCL, I 
> can be wrong...?

But what if somebody specializes your traits class? Then don't you lose
the concept checks?

I think explicit is better, so I prefer to place the concept check at
the top of the algorithm that needs it. Better yet, apparently now BCCL
has a BOOST_CONCEPT_REQUIRES macro (I havent used it).
A concept check is a kind of documentation as well :)

-- John