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

Subject: [ggl] namespaces, models and algorithms (was: namespaces and ADL)
From: Mateusz Loskot (mateusz)
Date: 2010-12-16 16:13:35

On 16/12/10 11:06, Barend Gehrels wrote:
>> 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.

My reasoning was that if there is only one function specific to ogc,
then namespace may feel redundant, thus I suggested use ogc-specific
name for function. If there are more ogc-specific elements, namespaces
may be sensible.

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

It's clear to me now and the current structure seems to make
sense, indeed.

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

Good. Sure, it's a matter of future.

Cheers,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org