Boost logo

Geometry :

Subject: [ggl] namespaces and ADL
From: barend (barend.gehrels)
Date: 2010-12-13 13:02:29


hi list,

We have recently worked on namespaces, according to this item from the
review report (a "minor non-contingency issue"):
Names of used concepts: currently the library is using mainly terms as
established by the OpenGIS Consortium (OGC). This is misleading for users
coming from different (non-GIS) domains. It has been suggested to introduce
different namespaces for the different geometry domains (GIS, graphics, 3D,
etc.) allowing to use the expected terminology established in that
particular domain

While these suggestions were good, and everybody seemed to agree, and I
added the namespace model:: ~2 weeks ago and was happy with it, we all
forgot one thing: ADL

ADL is Argument Dependant Lookup and worked in the previous version of our
library, before introducing the model namespace. ADL works for algorithms
found in the same namespace as the object.

So this worked:

boost::geometry::polygon<...> p;
std::cout << area(p) << std::endl;

This should work right away, so without qualifying area with a namespace,
because area is in the namespace of polygon and it is thus found by ADL.

There were no unit-tests for ADL so I didn't notice this was broken.

I don't know what people find that it is broken, but actually it might be
quite inconvenient.

Besides this major point, a minor point. I was happy with the model
namespace. But I had some doubts about the algorithms namespace, and the ogc
namespace, and the doubling of all algorithms that it involved. And the work
adding more namespaces for other domains, and the work on documentation it
involves. I'm afraid it will explode combinatorially again.
The review pointed out that OGC names are not that clear, and some are
indeed probably not (envelope). But I think the majority is clear enough.
Area, distance, intersects, centroid, convex_hull, intersection, union,
everyone using our library knows what it is. Confusion only occurs in some
of our (OGC's) names, and I think there are other solutions.
"within" might be aliased by the reversed "contains" (in fact OGC also does
this)
"envelope" might be aliased by "mbr" or "axis_aligned_bounding_box" or
"aabb" or whatever people prefer, or we can just say, if you use a library
you have to learn something...

A third reason for my mixed feelings is that most of Boost's libraries do
not use sub-namespaces. Many use the boost:: namespace (type traits, ranges,
graph, ...). Spirit uses namespaces but for different reasons, spirit
contains three sublibraries. There is (AFAIK) no subdivision into models and
algorithms, or namespaces to alias algorithms. The reason for not
sub-namespacing is probably... ADL.

I saw an email yesterday on namespaces and how things could work, and the
answer (ADL), and then I realized: that will be broken in our library now. I
tested it and indeed it is.

So my new proposal is:
* I remove the model namespace, and rename the ll::point back to point_ll
* I remove the d2 namespace as well; d2::point_xy was still called like
this, but I think point_xy is clear enough
* we will not add algorithms or ogc or other domain namespaces
* I will create a unit-test to ensure ADL is working for Boost.Geometry

While this is a sort of reversal of work, I'm not unhappy with this
excercise because many things are cleaned up during this action. I like
Bruno's suggestion on point_ll: there are no typedefs anymore and the units
can be specified right away. I like other suggestions to remove all
redundant typedefs in models. I can copy/replace all model:: so we can go
back in a few minutes, it is not a SVN revert. The model was some work,
namespaces for algorithms, ogc, deciding what is in where, extra
documentation and unit-tests would have been much more work and time which I
can better spend on other issues. But the main reason is ADL.

Regards, Barend

-------------------------------------
Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands,
www.geodan.nl

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101213/f61b9af7/attachment.html


Geometry list run by mateusz at loskot.net