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