Proposals:Refactoring Statistics Framework 2007 Transition Plan: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
No edit summary
Line 58: Line 58:
     filter->Update();
     filter->Update();
   #endif
   #endif
= Discussion =
== Option A versus Option B ==
=== Code duplication: ===
 
With A, if a file remains unchanged, it has to be duplicated (and maintained) in both directories.
With B, we have to worry only about the classes which need refactoring. Even refactoried files, where changes are minimal, you can even code of the form:
      namespace Statistics{ 
        class Blah {
          #ifdef ITK_USE_DEPRECATED_STAT
              void SetInputSample( ListSampleType * );
          #else
              void SetInput( ListSampleType * );
          #endif
        }
      }
=== Code separation and readability ===
Option A separates the classes clearly in two directories. The statistics library will be devoid of ugly ifdefs. If we decide to drop the deprecated version at some point, we simply have to terminate a directory.
We can do the same with Option B, in a less obvious way, by separating the classes in two files, for instance :
   
      File StatistiitkSample.h:
        #include "StatisticsDeprecated/itkSample.h"
        #include "StatisticsNew/itkSample.h"
       
      File StatisticsDeprecated/itkSample.h
        namespace StatisticsDeprecated
          {
          class Sample : public Object { ... }
          }
      File StatisticsNew/itkSample.h
        namespace StatisticsNew
          {
          class Sample : public DataObject { ... }
          }
=== Surprises ===
With Option A there are no surprises. I suspect that with B, using anonymized namespaces etc, in several translation units, some compiler might scream ? I tried to verify it with minimal C++ code on gcc4.3, but I feel uneasy about it.

Revision as of 20:42, 4 April 2009

Option A

  1. Rename the existing Statistics/ directory in ITK to StatisticsDeprecated/
  2. Create a parallel directory Statistics/ containing the new classes.
  3. Add an ITK_USE_DEPRECATED_STATITSTICS_FRAMEWORK option at configure time to toggle between the usage of the deprecated and the new framework. The option will cause (a) the right directory to be compiled (b) headers from there right directory to be installed (c) the right directory to be added to the include dirs.
  4. All existing code in the toolkit using the statistics framework will be ifdef'ed to work with both the new and the old framework. For instance :


 #ifdef ITK_USE_DEPRECATED_STATISTICS_FRAMEWORK
   calculator = Statistics::CovarianceCalculator< ListSampleType >::New();
   calculator->SetInputSample(sample);
   calculator->Update();
 #else
   filter = Statistics::CovarianceFilter< ListSampleType >::New();
   filter->SetInput( sampleGenerator->GetOutput() );
   filter->Update();
 #endif

Option B

Keep all files in a single directory but use two different namespaces

For instance the file itkSample.h would look like :

 namespace itk
 {
 namespace StatisticsDeprecated
   {
   class Sample : public Object { ... }
   }
 namespace StatisticsNew
   {
   class Sample : public DataObject { ... }
   }
 }

- The ITK_USE_DEPRECATED_STATITSTICS_FRAMEWORK option redefines the unused namespace to be an anonymous namespace. The used namespace to "Statistics". For instance :

   #ifdef ITK_USE_DEPRECATED_STATITSTICS_FRAMEWORK
     #define StatisticsDeprecated Statisticshow to put code in a wiki 
     #define StatisticsNew
   #else
     #define StatisticsNew Statistics
     #define StatisticsDeprecated
   #endif

User code still looks the same :

 #ifdef ITK_USE_DEPRECATED_STATISTICS_FRAMEWORK
   calculator = Statistics::CovarianceCalculator< ListSampleType >::New();
   calculator->SetInputSample(sample);
   calculator->Update();
 #else
   filter = Statistics::CovarianceFilter< ListSampleType >::New();
   filter->SetInput( sampleGenerator->GetOutput() );
   filter->Update();
 #endif

Discussion

Option A versus Option B

Code duplication:

With A, if a file remains unchanged, it has to be duplicated (and maintained) in both directories.

With B, we have to worry only about the classes which need refactoring. Even refactoried files, where changes are minimal, you can even code of the form:

     namespace Statistics{   
       class Blah {
          #ifdef ITK_USE_DEPRECATED_STAT
             void SetInputSample( ListSampleType * );
          #else
             void SetInput( ListSampleType * );
          #endif
        }
      }

Code separation and readability

Option A separates the classes clearly in two directories. The statistics library will be devoid of ugly ifdefs. If we decide to drop the deprecated version at some point, we simply have to terminate a directory.

We can do the same with Option B, in a less obvious way, by separating the classes in two files, for instance :

     File StatistiitkSample.h:
        #include "StatisticsDeprecated/itkSample.h"
        #include "StatisticsNew/itkSample.h"
       
     File StatisticsDeprecated/itkSample.h
        namespace StatisticsDeprecated
         {
         class Sample : public Object { ... }
         }
     File StatisticsNew/itkSample.h
        namespace StatisticsNew
         {
         class Sample : public DataObject { ... }
         }


Surprises

With Option A there are no surprises. I suspect that with B, using anonymized namespaces etc, in several translation units, some compiler might scream ? I tried to verify it with minimal C++ code on gcc4.3, but I feel uneasy about it.