Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-11 17:17:09

Hi Stefan,

Thanks for your comments.

>
>  - first of all, I'm curious why you chose to use one traits class for 
> each "agnosticism". this differs from the standard library, so I guess there 
> is a specific reason for it?
>   
Yes. It was discussed on the Boost List before. We're conforming to MPL
conventions here, so creating meta-functions, name things "type", etc.
We didn't want to create one blob trait.

>  - is there a default implementation of the traits classes? I haven't found 
> one in code/coordinate_dimension.
> this would simplify writing concept models in many cases, especially with 5 
> different traits for a Point.
>   
But there are registration macro's. They support different use cases. So
most people will not have problems adapting their classes to the concepts.

For points we've no default. For linestring we have (you can override
push_back). For polygon the clockwise orientation is default.

>  - on a minor note, tag<> seems a little non-descriptive, compared to 
> iterator_category in the STL.
>   
It is mainly for internal usage. It is the base for "tag dispatching" so
we thought that tag was appropriate. "geometry_category" could indeed be
an alternative but that never came up in our minds. And it is a little long.

> Boost.Iostreams and Boost.PropertyMap both use "category", which might also be 
> suitable for GGI, since it has its own namespace and there are no other 
> categories I assume.
>   
Yes, category is also an alternative and there are no other categories.
But it still is "tag dispatching" so if no one has big problems with
tag, I prefer to leave it like it is now. Library users will not have to
use it, unless they're implementing algorithms, or adapting geometries
without using macro's.

Regards, Barend