Flatten the namespace?

[tylerjw]

Currently, in MoveIt there are many namespaces, some of which are nested. For example moveit::core, moveit_ros_control_interface, moveit_servo, moveit_cpp, collision_detection, etc.

The whole point of namespaces is to prevent name collisions. The standard library mostly uses a single stl namespace. In the interest of making MoveIt code easier to read and easier to use, I suggest we migrate to a single moveit namespace.

@henningkayser, what are your thoughts on this?

[v4hn]

Duplicate of #1122

[tylerjw]

Migration Path?

• 1 large namespace (moveit) for all public interfaces of moveit (how each pacakge interacts with each other and the outside world)
• n number of modules in moveit expressed as moveit:: namespace for code that only that namespace should interact with

namespace moveit {

struct State {
  std::vector<double> variables;
};

State from_ik(Pose pose);

namespace core {

struct Kind;
Kind kind_from_string(std::string);

} // namspace core
} // namespace moveit

namespace moveit {

State from_ik(Pose pose) {
  auto k = core::kind_from_string("f1");
}

}

namespace moveit::core {

Kind kind_from_string(std::string);

}

We could do this incrementally by first figuring out what the public interface of moveit::core should be and moving those things to just the moveit namespace.

[henningkayser]

I really like the idea of using moveit for all public facing interfaces, but then we should define and limit what they are. I mean, is it basically MoveItCpp and MGI or how much of moveit_core would be counted as "public"? Also, thinking about the possibility of adding more free functions to core, I would prefer adding them to well defined domain-specific namespaces, e.g. kinematics, collision, visualization etc.. That way, documentation could be vastly simplified and separation of concerns could be enforced better as well. It will also be easier (or force us to) define what features are in scope of MoveIt and what features are not.

[tylerjw]

Agree we should be careful about what should be in the public API. I'm not so sure about having many sub-namespaces, though. I doubt we'll have many name collisions between them.

[henningkayser]

Let's continue this discussion, especially in the light of great cleanup PR's like this. First off, I'd note that namespaces are not only there to prevent name collisions, but they really are labels that define groups of code in a certain context like a module. They define terminology and help with orientation in the codebase. Therefore, I think it would be sensible to define a single naming pattern that we can use for namespaces, file structure and even logger names.
Assuming that all MoveIt packages follow the naming pattern moveit_<package_name>, how about we use the following naming pattern: moveit::<package>::<context>::<detail>, where context is reflects an optional submodule and subdirectory, and detail an optional file specification (for most files this is too verbose, but for some cases it makes sense). The logger name could follow this convention perfectly.

Then, if we want to flatten the namespace for our public API, I suggest that we provide a (single?) header file that defines this public API for convenience, and it should be use-case specific (MGI vs MoveItCpp). My concern is that if we remove the <package> it would lead to even more confusion between different concepts in MoveIt.