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-15 17:30:26

On 15/12/10 21:28, barend wrote:
> 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::

> ==================
> POSSIBLE-CHANGE 2: algorithms::
> 
> We planned to move all our algorithms to namespace 
> boost::geometry::algorithm::
> 
> The reason was that our algorithm-names were sometimes confusing. It was a 
> (minor non-contingency) issue from the review report.
> 
> As written, I think only a minority of our algorithms have unclear names. 
> area, distance, length, perimeter, intersection, it all can not be clearer 
> than this.
> 
> So moving to algorithms:: has not my absolute veto.
> 
> So algorithms::area, algorithms::distance, etc.

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

> It does not have my veto but I dislike it, because it is not necessary, and 
> because no other Boost library has this.

"no other Boost library" is not the strong argument
There is plenty of non-unified freedom of inconsistent styles in Boost
regarding structures or conventions used by libraries, so I'd risk
statement there is plenty of potential for improvements.

However, I agree it may be unnecessary to have
boost::geometry::algorithm namespace for standard Boost.Geometry
algorithms. Though, I'd personally find it useful to learn, navigate
through the software, etc.

> ==================
> POSSIBLE-CHANGE 3: algorithms::ogc and algorithms::graphics and 
> algorithms::3d etc
> What I find very unclear is the proposal to create namespaces for different 
> domains (e.g. ogc), having the same algorithms for the same types (all are 
> generic with respect to geometry concepts) repeated in each namespace (and 
> forwarding to a common implementation, I understand that).
> 
> So ogc::area being the same as algorithms::area, and ogc::envelope being an 
> alias for algorithms::mbr (try to find a neutral name...).
> 
> 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.

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.

> Personally I find those three, four, and more doubling of functions, with 
> the same or different names, completely unnecessary and unwished! All 
> algorithms will be multiplied, that is why I mentioned this another 
> combinatorial explosion. Only for the one or two functions that currently 
> seem to be unclear...
>
> This change will become more and more messy, from both implementator, 
> documentor and user's perspective. Totally unclear.

Yes

> No other Boost library has this.

So what :-)

> For these reasons, I object against this...
> 
> ==================
> NO-CHANGE: other namespaces
> In your mail you mention namespaces for dispatch, going to implementation, 
> etc. That all has been realized and I didn't propose to change that. It is 
> very useful. Those are detail namespaces, not exposed to library users.

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

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.

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