[Insight-developers] Integrating the New Statistics framework into ITK

[Bill Lorensen]

I certainly agree on the #ifdef explosion and the difficulty of
testing the combinations. That's one reason I prefer building both the
old and new statistics.

I do think we need to try hard to reduce the maintenance.

However, I have argued for years that developers will ALWAYS take the
path that is easiest fro them with less concern about the impact on
customers.

Recently, we discovered that a non threaded version of the shrink
filter was still around. The easy thing for the developer is to just
deprecate it and remove it later. But, with a little thought, we were
able to retain it with virtually no duplicate code and very little
maintenance burden.

Bill

On Thu, Apr 9, 2009 at 4:51 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>
> On Apr 9, 2009, at 4:22 PM, Luis Ibanez wrote:
>
> Bill Lorensen wrote:
>
> Just a few initial comments:
>
> I see in general that Calculators have been replaced with Filters. It
>
> is a great idea to have filters. However, I'm suprised that the
>
> calculators are gone. In other parts of ITK, we have both Calculators
>
> and Filters. The Filters are implemented using the Calculators.
>
> I wonder was there any consideration to minimize backward compatibility
> issues.
>
> ...
>
> But...
> we don't have both a MedianImageFilter and a MedianImageCaculator,
> we don't have AnisotropicImagefilter and AnisotropicImageCalculators
> ... etc... That is, not every filter is duplicated into a calculator.
>
> This latter will be more a duplication of functionality (not to
> mention a maintenance nightmare).
>
>
>
>
> On Apr 9, 2009, at 9:25 AM, Stephen Aylward wrote:
>
> On Thu, Apr 9, 2009 at 8:21 AM, Hans Johnson <hans-johnson at uiowa.edu> wrote:
>
> GREAT!  A consensus is being reached.
>
> Result: Backward compatibility trumps fixing inconsistent behavior!
>
> Actually...
> "Backward compatibility trumps all" (c) 2009 (TM) All rights reserved.
>
> I think maintainability can be more important the backwards compatibility in
> some cases. I have concerns about the number of duplicate files, number of
> needed #ifdef, and then number of builds that will be needed to get good
> coverage on yet another build option. We don't want ITK to collapse under
> it's own weight of maintainability.
> I also don't have a clear idea of what the goals of integration are. What
> are the possible choices? How may other files in ITK depend on the
> Statistics? How will they be ported?
> I am under the opinion that both need to live together for a transition
> period, and then warn the user community of the impending change. In this
> case, if a user wants the old statistics, perhaps we could have an separate
> library for users to utilized these deprecated classes. This would be
> very similar to how I am now using the re-factored statistics now, it's just
> another library in my programs.
> Brad
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>