Geometry Boost List: [ggl] namespaces and ADL

Subject: [ggl] namespaces and ADL
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2010-12-14 12:58:41

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

I believe the difference is, that you're separating _concepts_ and
functions. 

However, you're right, the functions should be in the same namespace as the
corresponding functions. Your current (main) algorithms are just trampolines
to the concrete algorithm implementations for a concrete model. 

I believe that's the source of this confusion/discussion.

Normally, if you have several different types implementing a certain
concept, you'd move those into different namespaces; certainly along with
the algorithms/functions belonging to this particular type. All is well in
this case, as ADL will find the proper algorithm for the proper type.

What you currently have is a central algorithm, which does nothing more than
to dispatch to the proper algorithm implementation based on the types of its
arguments. This is necessary, as several different models (types
implementing a certain concept) might share a specific algorithm.

In the end you have two possible solutions:

a) move the models back into the main namespace for ADL to find them

This clutters the main namespace with models and provides a specific
solution for a certain amount of models, but definitely not the user defined
ones. This solution does not scale.

b) pull the proper algorithms (perhaps not even the main ones) into the
model namespace for ADL to find them. 

This is extensible, as even user defined types can pull in the proper
algorithm into their namespace, allowing for them to work with ADL as well.
The main algorithms can still be used if the user does not want to pull in
all algorithms into his namespace, while sacrificing ADL.

Another idea (but I'm not sure if that's possible) is to associate the
algorithms in terms of ADL with the traits specializations describing a
particular model. The rules of ADL are very complex and not restricted to
the actual types involved, but extend beyond that to include types, which
are somehow associated with the argument types.

Regards Hartmut
---------------
http://boost-spirit.com