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

Subject: [ggl] namespaces, models and algorithms (was: namespaces and ADL)
From: barend (barend.gehrels)
Date: 2010-12-15 16:28:11

hi Hartmut,

Thanks for your long answer. I think there are some confusions indeed.

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.

What I was concerned about is the namespaces for the library users.

Until a few weeks ago, for the library user everything was in namespace 
boost::geometry (besides coordinate system tags in boost::geometry::cs).

Now we proposed to change it, because of the review report and because this 
idea was discussed already about a year ago on this list.

==================
CHANGE 1: model::
So I already moved geometry models, provided by the library, to namespace 
boost::geometry::model::

I did propose to change it back indeed, to support ADL. But as most people 
object against this, and are happy with model::, it is OK for me, we can do 
without ADL, and users can provide their own geometries indeed, having no 
ADL support neither. Or pull it in with a using clause like described.

So I agree on that. It can stay as it is now.
So, for example model::polygon<model::point<double, 2, cs::cartesian> >

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

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

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

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.

No other Boost library has this.

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.

Hoping having cleared some things...

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101215/88ed80a5/attachment.html