Subject: [ggl] namespace renaming
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-12-01 03:48:09
>> 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.
Barend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091201/aa4772d6/attachment.html