Geometry Boost List: [ggl] namespaces and ADL

Subject: [ggl] namespaces and ADL
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2010-12-14 09:11:18

> 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.

My personal opinion (and I admit I might miss the full picture) is to prefer
having a clean library structure over ADL. Therefore, if you ask me, I'd
keep it the way you have it right now. For user defined types ADL wouldn't
work anyhow and for your own types you can always pull all algorithms into
the namespace your models are defined in:

namespace model 
{
    using boost::geometry::algo::area;
}

This should do the trick.

Regards Hartmut
---------------
http://boost-spirit.com