Geometry Boost List: [ggl] namespaces, models and algorithms (was: namespaces and ADL)

Subject: [ggl] namespaces, models and algorithms (was: namespaces and ADL)
From: Barend Gehrels (barend.gehrels)
Date: 2010-12-16 06:06:36

Hi Mateusz,

>> As for namespaces, we have internally various namespaces, dispatch::,
>> traits::, detail::, the last one with per algorithm another namespace. That
>> is all internal to the library.
> Yes, though somestimes I've been getting lost myself as well
> unsure of traits or dispatch is public or implementation detail.
> It is not public, as far as I understand, but it lives outside the detail::

(you just answered this in new mail, good...)

> Is it boost::geometry::algorithm:: or boost::geometry::algorithms::
> Personally, I'd prefer the former, more natural and STL'ish :-)

I agree on making singular/plural consistent.

> "no other Boost library" is not the strong argument

We conform to Boost libraries and target them. Besides this the std:: 
library also does not have a namespace for "algorithm::" (though they 
have a headerfile)

But I understand and agree to some extent, one library might be the first.

>> (...)
>>
>> Then we get gaming::area, cg::area, robotics::area, astronomy::area. All
>> pointing to the same area function, of course, because area has no other
>> meaning than calculating the area. And we get gaming::aabb, robotics::bbox,
>> astronomy::bounding_rectangle, etc... all pointing to the neutral
>> algorithms::mbr.
> Yes, here things may become hairy and muddy, indeed.

OK
> The domain-specific namespaces do not quite sound for me.
> Especially if there is potential for repeated code.
> What having distinct algorithms in the same boost::geometry::algorithm::
> but with different name: area, ogc_area.

I see ogc_ similar to ogc:: but worse because it is like a namespace but 
not indicated as such.

> I actually think Hartmut has a point. boost::geometry::traits does not
> suggest it's an implementation detail, and I'd bet users may want to use
> them. I'd move all details down in to boost::geometry::detail::,
> namely boost::geometry::detail::traits, boost::geometry::detail::dispatch

Traits is handled above, and for dispatch, I might agree but this is a 
totally new point.

It is currently like this:
namespace detail { namespace centroid
{
// implementation deails
}}

namespace dispatch
{
template<typename Tag, typename Geometry, typename Point, typename Strategy>
struct centroid {};
// specialized classes derived from e.g. : 
detail::centroid::centroid_polygon<Polygon, Point, Strategy>
}

If dispatch goes into the detail::centroid, we have a struct centroid 
within a namespace centroid. If distpach goes into detail, it... will 
probably work (I've the feeling that there was an issue in the past but 
cannot reproduce it).

Library users might (will not be frequently) specialize their own 
dispatch function. This is done in c04_b_custom_triangle_example.cpp

This is done in the article, in the review, in the example.

Therefore, I also object to moving dispatch into detail...

>
> By the way, I'd like to touch one more thing, extensions.
> Are we going to decide anything here?
> For instance, total freedom, extensions sit in common namespace
> boost::geometry::ext or their dedicated namespaces like
> boost::geometry::ext::<name of extension>
>
> I'd refer to the idea of Java packages which I quite like
> personally and consider as making things easier to find and kept in order.

Yes, this is a very good point. I believe boost::geometry::ext is very 
convenient. About names of extensions, don't think about this yet.

Thanks, Barend

p.s. thanks also for your answer which just arrived.