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

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

> 
> John wrote:
> >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.
> 
> 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.
> 
> That said I was already leaning in the direction of making 
> the coordinate_type typedef a meta-function and moving it out 
> of the traits.
> 

Well, I hope you do go with metafunctions, I just think they are more
flexible.
CGAL has been around for a long time, and it is a good library that has
a more restrictive license situation than boost.  I personally dont use
it (it is forbidden to me) but my colleagues love it, and I think any
boost geometry library has to work well with it. It is old, but quite
generic, and it is an extremely active project.  It is also peer
reviewed (by editors), so the stuff that is in it is vetted and
important for real world problems.

http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Kernel_23_ref/Concep
t_Kernel.html#Cross_link_anchor_0

Also, traits bundle together a lot of values that dont _need_ to
coupled. I can let somebody else make this point:
http://www.ubookcase.com/book/Addison.Wesley/CPP.Template.Metaprogrammin
g/0321227255/ch02lev1sec2.html

"The traits templates in the standard library all follow the "multiple
return values" model. We refer to this kind of traits template as a
"blob," because it's as though a handful of separate and loosely related
metafunctions were mashed together into a single unit. We will avoid
this idiom at all costs, because it creates major problems.",  this is a
good book BTW