Geometry Boost List: [ggl] namespaces and ADL

Subject: [ggl] namespaces and ADL
From: Barend Gehrels (barend.gehrels)
Date: 2010-12-14 12:31:42

Hi Bruno, Hartmut, list,

Thanks for your comments.

> If I understand correctly, before the namespace change, we had:
> - boost::geometry::polygon class
> - boost::geometry::area function
>
> Now we have:
> - boost::geometry::model::polygon class
> - boost::geometry::algorithms::area function

This is close to correct, but the ::algorithms namespace has not yet 
been realized.

So currently we have:
- boost::geometry::model::polygon
- boost::geometry::area

The algorithms namespace was meant as a "neutral" namespace, to be 
worked out for ogc, computing geometry, etc.

However, I'm not so sure about that now. I don't want to explode 
namespaces, make different functions with the same name and different 
names for the same function, etc. It 's going to be too complex like this.

Suppose we have algorithms::area. Clear as it can be.
I hesitate to add ogc::area, cg::area, gaming::area, all because we want 
to have namespaces for all domains. I find it too much.

Furthermore, what is an algorithm. area is, but is "num_points" one? 
Only counting. OK, it is one. Is "exterior_ring" one? Giving the 
reference/value back from the traits class / from the polygon...

There will be much work in deciding what is what. Then applying it (will 
be the minor part) and then the increased work on documentation.

Finally, it requires also more knowledge from library users which 
namespaces things are in, and more confusion because the same things are 
in multiple namespaces under different names...

Therefore my doubts, which I already had before ADL, and I was more or 
less glad that I found a technical reason as well...

>
> So area is no longer found by ADL. Both changes have to be reverted so 
> that ADL works again. Is my understanding correct?

Only the change to model::

>
> If yes, then I would like to point out that we have the same problem 
> for custom types anyway (which are the whole point of Boost.Geometry). 
> You will typically end up in the following situation:

Yes, that is right, ADL will not work for custom types. I realized that 
when writing it. I think that is no problem.

I like to support ADL for our out-of-the-box types. It might even be 
that our reviewers have tested this and thought "OK, this works, right", 
and if it would not have worked they would maybe have commented it.

---
re: other mails / Hartmut's mail / I've got an off-list mail for this as 
well:
So there is a mechanism () to pull in ADL. Good. But, as Bruno mentions, 
that will give another task of mentioning each (new) function there.
So in summary, I actually don't understand why namespaces are that 
important to us. I quote from the off-list mail that I got:
"As we all know, open functions that are part of the class interface 
must be declared in the same namespace as the class. "
Most (if not all?) other Boost libraries don't have this separation for 
classes and functions.
Regards, Barend