Geometry Boost List: [ggl] namespace renaming

Subject: [ggl] namespace renaming
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-12-01 11:42:42

> I hope you don't mind me referring to Spirit again :-P
>   
Certainly not ;-)

> There we have 3 sub-namespaces (actually 4, but the last one is not relevant
> here): Qi, Kamra, Lex. All three share the same symbols (such as int_,
> char_, etc.) even if those have different meaning in different contexts.
> What we did is to provide the general names and either overloaded the same
> name in the sub-namespace (if needed) or just added a using directive
> hoisting the names into the sub-namespace.
>   
Good to know, interesting.
> For GGL this might be a bit more difficult as the names are different, or
> similar names refer to different things. One solution could be to have a
> independent sub namespace (i.e. algorithm) containing all the shared
> implementations
This sounds like a convenient name, and solution.

>  and thin wrappers in the domain specific namespaces either
> redefining or re-using/hoisting the existing algos from namespace algorithm.
>   

I understand redefining/inlining and calling, but how can you hoist a 
function with the using clause?

> This way you'll end up with some domain agnostic core and domain specific
> wrappers around this.
>   
I think this basically is a good solution.

We then get:
boost::geometry::algorithms::distance (the agnostic namespace)
boost::geometry::ogc::distance (forwarding the call)
boost::geometry::cg::distance (forwarding the call)

For the algorithms not (yet) categorized, uses can call:
boost::geometry::algorithms::simplify (not (yet) categorized

Brainstorming, for geometries we can do the same, but here we can use 
more convenient typedefs, so:
boost::geometry::geometries::point<type, dimensions, coordinate system>  
// in the agnostic namespace, e.g. "geometries"
boost::geometry::ogc::point // typedef's 2D double point in cartesian (I 
know that OGC has 3D points as well, but most in 99% of the cases it is 2D)
boost::geometry::d3::point // typedefs 3D double point, so this instead 
of the current boost::geometry::point_3d

and, more interesting:
boost::geometry::ogc::polygon // typedef's naming-agnostic 
"polygon-with-holes" to polygon
boost::geometry::cg::polygon // this would then be a polygon without 
holes because that is how most people in computational geometry define 
it, and e.g. cg

So this would solve also discussions around polygons having or not 
having holes.

However, for usage within Boost.Geometry agnostic namespace, and also 
for the concepts, we still have to have a consistent naming scheme to 
avoid confusions (though even concepts can be forwarded/redefined, and 
registration macro's can, but the traits cannot).

Barend