Geometry Boost List: [ggl] namespace renaming

Subject: [ggl] namespace renaming
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2009-12-01 10:43:27

> All library users have to modify sources then, by renaming the used
> namespace (or using an alias), or renaming macro's.
> 
> 
> I'd add that this is one time operation and for good.
> No more renaming in foreseen future, in case anyone would have doubts.
> 
> For the top level namespace, right. But we are not yet there. There was
> a suggestion during review to add namespaces per domain, and therefore
> to move all OGC functions into a separate namespace, on which everyone
> seemed to agree.
> 
> boost::geometry::ogc::envelope would be the same as
> boost::geometry::cg::bounding_box and
> boost::geometry::game::axis_aligned_bounding_box
> (these samples are artificial).
> 
> So some extra namespaces and code modifications are unavoidable.
> 
> It will not be trivial to get a scheme which is satisfactory for
> everyone. For OGC it is less complicated, because that is a standard.
> So we will get:
> boost::geometry::ogc::area
> boost::geometry::ogc::centroid
> boost::geometry::ogc::distance
> boost::geometry::ogc::envelope
> etc
> 
> For intersection_inserter it is questionable, because the ogc name is
> "intersection" (and that one is planned as well).
> For non-OGC (but normally found together) functions as simplify, where
> will they go?
> For a function as "distance", which is probably called "distance"
> everywhere, omit namespace? boost::geometry::distance Or get an alias
> for all domains (probably yes)
> 
> I don't have the solution yet, any ideas are welcome. We could start
> creating a list with namespaces covered, and the list on
> http://trac.osgeo.org/ggl/wiki/OGC.

I hope you don't mind me referring to Spirit again :-P
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.

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 and thin wrappers in the domain specific namespaces either
redefining or re-using/hoisting the existing algos from namespace algorithm.
This way you'll end up with some domain agnostic core and domain specific
wrappers around this.

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com