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
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
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).
Geometry list run by mateusz at loskot.net