Geometry Boost List: [ggl] namespaces and ADL

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