[Insight-developers] interrupting filter execution

Paul Koshevoy koshevoy at sci.utah.edu
Mon Jul 24 23:49:29 EDT 2006


Stephen R. Aylward wrote:
> I agree with Jim - base classes shouldn't provide functions that imply
> functionality that cannot be provided by the majority of its subclasses.

That's a good point. Notice however, that the current itk::Transform already
declares functionality that may not exist:

	bool GetInverse(Self * inverse) const { return false; }

<RANT>
Early last year I wrote a cascaded transform class, which was nothing more than
a list of pointers to other transforms. All that was required of the constituent
transforms was that their in/out dimensions match up. The cascade could consist
of any number of types of transforms -- translation, affine, radial distortion,
etc... It's really not important, what's important is that the exact type of the
transforms stored in the cascade was unknown. An inverse of this cascaded
transform is trivial -- you simply walk the list backwards, call GetInverse (or
BackTransformPoint) and use the results at the next link in the cascade.
However, since the exact type of the forward transform at each link is unknown,
a virtual GetInverse function was required. That's the kind of flexibility I
needed from the ITK Transform API -- but it didn't exist, so I had to go patch
it in.

The annoying thing is that to get the functionality I needed all I had to do
were very minor changes at the itk::Transform class level, and then cosmetic
fix-ups for a few Transform classes that already provided the GetInverse
functionality. The changes were/are so small that I am still confused as to why
the code wasn't written that way from the start.
</RANT>

Is the flexibility that I am after even achievable without declaring
functionality that may not be provided by the subclasses?

BTW, what's wrong with run-time verification of the existence of inverse
transform functionality?

	Paul.


More information about the Insight-developers mailing list