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
> (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:
> 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
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.
Meet me at BoostCon
Geometry list run by mateusz at loskot.net