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

[Stephen R. Aylward]

I think the ITK_VERSION_3_2... solution is not a good idea.

We are then committed to maintaining multiple versions that will grow in 
incompatibility, we are opening the door to arbitrarily breaking 
backward compatibility by allowing programmers to only consider the 
future and turning off the past, and this solution does not scale -- the 
complexities grow exponentially.

Imagine writing a class B that uses a class A that has two or three such 
#if VERSION... clauses in it - how do I test my code?   Do I have to 
write a test for each version or do I have to wrap all of my code in an 
#if VERSION too?   If I only test for the current version - then chances 
are that it won't work for a previous version (Luis Rule #27: if you 
don't test it, it is broken), so we are not actually providing backward 
compatibility.

People can get previous versions of ITK by downloading previous versions 
of ITK.   We shouldn't try to mix within a single release.

Old-Bill Rule #1: ITK must be backward compatible.   I agree.   We can 
turn off new features (ITK_USE_CONCEPT CHECKING) because we can control 
the scope of their effects (but I admit even this is risky) but we 
shouldn't attempt to maintain backward compatibility via #defs - that is 
an entirely different approach / concept that ITK has chosen not to adopt.

Stephen

Brad King wrote:
> Peter Cech wrote:
>> Turning off whole class of constructs on compile time works for backward
>> compatibility, but if you develop new code in parallel, concept check at
>> right place might save you a lot of time (been there). What about
>> version-targeted backward compatibility instead?
>>
>> What I mean is enabling backward-compatible or backward-incompatible fix
>> depending on user choice. For the current situation it would look like:
>>
>> - If ITK_3_2_COMPATIBILITY <= VERSION(3,2), a backward compatible bugfix
>>   (runtime error reporting) is enabled.
>>
>> - If ITK_3_2_COMPATIBILITY > VERSION(3,2), a backward incompatible
>>   bugfix (concept check) is enabled.
>>
>> What do you think about it?
> 
> Good idea!
> 
> This is the approach CMake uses with the "CMAKE_BACKWARDS_COMPATIBILITY"
> variable.  It may be set by the user to a value smaller than the current
> version of CMake.  Then when a breaking change is made we set things up
> to check the value of this variable.  The old behavior is maintained if
> the value of the variable is low enough.
> 
> In CMake this variable defaults to the value of the current version for
> a new build tree.  Error messages that are related to the breaking
> change include the version number to which CMAKE_BACKWARDS_COMPATIBILITY
> must be set to disable the message.  This has the advantage that new
> development and new projects will always get the most modern behavior
> while still allowing existing code to work.  Existing build trees
> created by older versions of CMake will already have the variable set to
> the older version in the cache, so users with existing build trees do
> not need to touch anything when they upgrade.
> 
> We can probably design a similar solution for ITK.  However the trick is
> that the backwards compatibility level required may be different for
> each project using a single ITK build.  Perhaps the build of ITK should
> have a CMake option specifying the oldest level of compatibility to
> support (for changes in the compiled binaries).  Then a preprocessor
> definition can be used to adjust concept checking rules.  Whenever a
> concept check is added it is put inside a compatibility test against the
> current version.  A macro can package up the test to make it readable:
> 
> #if !ITK_COMPATIBILITY(3, 2)
>   // Concept check here...
> #endif
> 
> Next we need to find a way to get the compatibility version information
> into the concept check error message.  It shouldn't be too hard to
> encode a type describing the version of the check.
> 
> -Brad
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> 

-- 
=============================================================
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - Chapel Hill Office
http://www.kitware.com
Phone: (518)371-3971 x300