[Insight-developers] ConceptCheck & Wrapping : ITK 3.4 Update

[Luis Ibanez]

Good point,
let's take a look back at the original concern that Bill pointed out:


       How easy is for that developer (ITK user) to figure out
       what needs to be fixed in her applications in order to
       adopt a new ITK version.


Run time warning error messages are a possible alternative here too.

We could just test the pixel type to see if it is float or double and
insert an itkWarningMacro() when it is not.

This will generate a run-time annoyance that will motivate the
application developer to fix the application, and will bring
the opportunity to present a clearer message on what the error
might be, and now to solve it.

In the particular case at hand : FiniteDifferenceImageFilter
We could add an itkWarningMacro() with the message:

      "Output pixel type should be float or double
       in order to prevent computational errors."


or something along those lines...


    Luis



-------------------
Brad King wrote:
> Luis Ibanez wrote:
> 
>>
>>This sounds indeed like the right thing to do,...
>>*for one release*...
>>
>>   but...
>>
>>
>>We shouln'd understimate the cost/effort of maintaning
>>such a system for the next five to ten years.
> 
> 
> I agree that the technique is not that maintainable.  It is just an
> example of how to implement full compatibility without allowing new code
> to use the old behavior.
> 
> There are two kinds of compatibility: feature compatibility and "bug
> compatibility".  The case discussed in this thread is a bug
> compatibility issue.  We have replaced a subtle runtime bug (integer
> truncation of results) with an explicit compile-time message.  One could
> argue that this change is a feature enhancement.  I think less effort
> should be spent on bug compatibility.  As long as the breakages are
> documented the fixes should not be a problem.
> 
> Going back to Bill L's young grad student example, if he/she has been
> given the task of updating an application to use a new ITK release, then
> the task inherently involves dealing with issues like the resulting
> error message.  If the application has been working well for years with
> an older ITK, then why upgrade?  Obviously in order to get some new
> features.  The cost of getting the new features is a couple minutes
> fixing a few compiler errors on code that had a bug anyway.
> 
> -Brad
>