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

[Bill Lorensen]

I like this solution. It's simple and informs the user how to correct a
mistake we made as ITK developers.

Bill


On 9/21/07, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
>
> 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
> >
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20070921/637114dc/attachment.htm