Namespaces vs Static Classes

In PR https://github.com/KratosMultiphysics/Kratos/pull/7039 a discussion started about exporting to python free functions as part of new user specified namespaces.

After discussion in https://github.com/orgs/KratosMultiphysics/teams/technical-committee we reached the consensus to keep the current usage, that is, to have static methods exported as members of classes and not as free functions within specific namespaces

The rationale of this is

• Classes allow private members and methods while namespaces don't
• Classes can be templated
• KRATOS_API has to be added only once

On the other hand the https://github.com/orgs/KratosMultiphysics/teams/technical-committee agrees in principle about adding a limited number of namespaces, on the line of "internal", "utilities", "processes" in order to better organize the code and to benefit of better code suggestions by modern editors. However to avoid the proliferation of such namespaces we require that this is agreed to by the https://github.com/orgs/KratosMultiphysics/teams/technical-committee

We shall also observe however that adding such namespaces for existing classes, for example for processes and utilities, would imply a very large effort, so we would need to consider this carefully before actually doing it.