[Insight-developers] Need for decoupling Traits from Vector-like containers

[Bill Lorensen]

I'm sorry I won't be on the t-com today (Vis in SLC). I still think a
solution should be found that will retain backward compatibility.
Let's try a little harder.

On Tue, Oct 26, 2010 at 10:12 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Gaetan, Bill,
>
>
> The change
> http://review.source.kitware.com/#change,224
>
>
> Is intended to decouple the Traits from
> the Vector like containers.
>
>
>
> There are two main reasons for this change:
>
>
> A) The Generic Programming justifications:
>
>   Traits take two flavors:
>
>   a) They may be types defined inside a class X
>
>   b) They may be types defined in a helper class
>        that is templated (and potentially specialized)
>        over class X
>
>   When we opt for the case (b) is because the class
>   X can't or shouldn't not be aware of the traits, or
>   because we have no access to modify class X
>   as to allow the introduction of the traits (that case(a)
>   will require).  Think, of the std::vector for example,
>   or the basic types (int,double...) over which we have
>   no control nor access to modifications.
>
> Once we opt for (b), as we did in NumericTraits,
> in order to avoid circular dependencies, class X
> shouldn't  know about the Traits helper class,
> because that helper class  in some cases needs
> to know about Class X.
>
> This specific circular dependency is the reason
> that lead us to decouple the Specialization of
> the Numerics traits from the actual Vector-like
> classes.
>
>
> I agree with you in that, in itself the change,
> doesn't seem to justify the pain that it will
> inflict in users, who will have to reintroduce
> the traits.  However, this changes is a stepping
> stone in a much larger modification that is required.
>
> and that modification is our reason (B) below:
>
>
> B) The Statistics framework to be of large
>       general use, should be able to instantiate
>       itk::Sample types over a large variety of
>       vector-like classes (that we usually refer to,
>      as the "MeasurementVectorType".
>
>      This includes typically:
>
>      * itk::Array<t>
>      * itk::FixedArray<t,n>
>      * itk::Vector<t,n>
>      * itk::Point<t,n>
>      * itk::CovariantVector<t,n>
>      * vnl_vector<t>
>      * vnl_fixed_vector<t,n>
>      * std::vector<t>
>
>
>   To make the itk::Sample< MV > be
>   instantiatable with MV= any of the
>   types above, a certain number of
>   operations and types must be standardized.
>
>   In particular:
>
>        int  GetLength()
>        void SetLength(int)
>        Set to Zero
>        The Real type of the equivalent MV
>
>   Up to now, those traits were encoded in
>   a new family of Traits that were introduced
>   ad-hoc in the Statistics refactoring, and
>   were generally called
>
>         MeasurementVectorTraits<>
>
>   As part of recent cleanup in the Statistics
>   Framework, Brad L. pointed out (and I agree)
>   that the role of the MeasurementVectorTraits
>   should have been fused with the pre-existing
>   NumericTraits that are available to existing
>   classes.
>
>    Additionally, in order to use the Statistics
>    framework with scalar images, we typically
>    instantiate vector-like types of size = 1.
>
>    We discussed the options with Brad and
>    Gabe and converged to the idea that
>    a VectorType trait should be added to the
>    basic types NumericTraits in order to
>   generalize access to this concept.
>
>    So,
>
>     NumericTraits<double>::VectorType
>
>     should be defined as
>
>            itk::FixedArray<double>
>
>
>
> ------------------------
>
> To summarize,
>
> This change that Gabe is introducing
> is a atomic step that prepares the code
> base to much larger changes that are
> required to improve consistency in the
> Statistics Framework.
>
> Regarding backward compatibility and
> the need to assist users during the
> migration, Gabe is actually using this
> changes as the role model for how
> migration information should be collected
> and presented to future users.
>
> Gabe have prepared a very detailed
> description of the draft proposal for
> migration support at:
>
> http://itk.org/Wiki/ITK_Release_4/Users_Migration_Guide/Developer_Migration_Guide_Workflow
>
> (looking at the PDF is quite helpful since
> it looks closer to an animation of the process).
>
> Gabe's commit includes an XML file
>
> http://review.source.kitware.com/#patch,sidebyside,224,2,Migration/DecoupleNumericTraitsFromContainers.xml
>
> (that we have discussed with Julien Jomier
> and Hans Johnson) based on what Qt did
> for migration from Qt3 to Qt4:
>
> http://doc.qt.nokia.com/4.0/qt3to4.html
>
>
> This XML file contains all the documentation
> that will be then converted into a web page
> for the Migration Guide web site.
>
> At this time, we are experimenting with two
> systems:
>
> 1) phpbb:
>
> http://www.insight-journal.org/itkforum/viewforum.php?f=2&sid=fd5100d0689c9299fed0ca72a5f5b955
>
> see for example:
> http://www.insight-journal.org/itkforum/viewtopic.php?f=2&t=5
>
> and
>
> 2) phpFAQ
>
>    http://ij.itk.org/itkfaq/
>
>
>
> ---
>
>
>      Luis
>
>
>