Are we satisfied with ITK namespaces?

Engineering
1

Folks,
due to a recent issue reported to the ITK Software Guide project, I’ve investigated the use/appearance of nested namespaces in ITK.

I’ve identified the following list of namespaces:

  • Accessor
  • Algorithm
  • Concept
  • Detail
  • ImageToImageFilterDetail
  • fem
  • fftw
  • Function
  • Functor
  • GTest
  • i18n
  • LibraryA
  • LibraryB
  • LibraryC
  • Math
  • mpl
  • NeighborhoodAlgorithm
  • op
  • Predicate
  • SpatialOrientation
  • Statistics
  • Testing
  • v3
  • watershed

I’m wondering whether, taking advantage of the upcoming ITKv5 we should think about making them adhere to the Coding Style Guide in the ITK Software Guide (see Naming Namespaces).

Or else, whether other appropriate updates we may come up with can be incorporated (including dropping some if we deem it wise).

I know this is delicate due to backwards compatibility/API break, but I’m bringing it since it is a major version change.

Among others, and although this is a minor detail, I’ve found discrepancies in the namespace ending comments, e.g.:

namespace Function
{

} // end namespace functor

See, for example, itkAutumnColormapFunction.h.

If this needs to be changed regardless of the (potential) above changes, let me know, and I’ll submit a patch set to gerrit.

Clarifications, comments and suggestions are welcome.

2

A good issue to discuss, but I think changing the existing namespaces will cause much more pain than benefit by breaking backwards compatibility.

1 Like
3

Name spaces provide some unique flexibility namespace alias and using namespaces to import one namespace into another.

If these names are offensive enough, the ITK code itself could be updated to the conforming name conventions, and the legacy ones be made as a alias to the new ones.

But to actually update everyones code and all the examples to the the proposed namespaces would be too much work without little gain.

1 Like
4

Thanks for the replies.

IMHO, the alias option would not address the root, but it is interesting to know that it exists.

In any case, I share the idea that it would bring more problems than benefits, so +1 to keeping what we have.

I’ll send a topic to gerrit to remove the documentation inconsistencies.

1 Like