[Insight-developers] [Insight-users] INSIGHT JOURNAL: managedITK (ITK 3.8 ?) & Release Schedule

[Dan Mueller]

Hi Bill,

2008/7/15 Bill Hoffman <bill.hoffman at kitware.com>:
> I am going to make some harsh statements at this point....  Sorry Dan...

Go right ahead.

> My guess is spatial objects are not wrapped because it would have to be done
> by hand.  ManagedITK, while it manages to wrap the current ITK, is IMO
> unmaintainable.  It is essentially a hand wrapping of ITK.  There is no
> parsing of the C++ headers.  Each and every method that is wrapped by
> ManagedITK has to be specified in the cmake files for ManagedITK.

I never claimed ManagedITK had automated wrapping. Sorry if you feel
mislead in this regard.

> Here is an example for a single pair of set/gets on a class:
>
> BEGIN_MANAGED_PROPERTY("LowerThreshold" GETSET)
>    SET(MANAGED_PROPERTY_SUMMARY   "Get/set lower threshold value for
> detected e
> dges.")
>    SET(MANAGED_PROPERTY_TYPE      "itkPixel^")
>    SET(MANAGED_PROPERTY_GET_BODY  "return
> itk::ManagedTypes::ToManagedPixel<Nat
> iveType::OutputImagePixelType>( m_PointerToNative->GetLowerThreshold() );")
>    SET(MANAGED_PROPERTY_SET_BODY "m_PointerToNative->SetLowerThreshold(
> itk::M
> anagedTypes::ToNativePixel<NativeType::OutputImagePixelType>( value ) );")
>  END_MANAGED_PROPERTY()
>
>
> I would vote/recommend that ManagedITK not be incorporated into ITK, but
> remain an external project.   If it is incorporated, each time you add a
> method or change a method, then you would also have to find the
> corresponding wrapping file in ManagedITK and make the same change.

ManagedITK was created by me to serve a specific purpose. It has since
served that purpose. I shared it with the ITK community hoping it may
help others, which seems to be so. By the way, it was Luis who brought
up the idea that ManagedITK be included in the toolkit.

> We have a complete C++ parser available to us in gccxml, and we should be
> using it.  I would suggest that ManagedITK is a great proof of concept, but
> is not practical in the long run.  The real solution is to either use the
> swig based wrapping for C# or at a minimum use gccxml to parse the classes
> and then generated the CLI class wrapping automatically.  ITK is a large
> complex set of objects, and having to maintain the interface in both
> templated C++, and .cmake configuration files for each class wrapped will
> just be to hard to maintain.

Your statements are quite valid.

However, let me also point out that ITK does not (yet) support SWIG,
let alone C# wrapping. Even if it did, I have serious doubts about the
capabilities of this wrapping system (however, I could well be proved
wrong in this matter).

So, let me state my position. Until such time that ITK supports C#
wrapping superior to that provided by ManagedITK, I will continue to
maintain it by hand (as best I can) and make it available (whether
that is by the Insight Journal, Insight Applications, or some other
public repository such as Google Code or Source Forge). This will mean
that, yes, some things will be not wrapped immediately (eg.
SpatialObjects) and that adding a new method requires some fingerwork
(ITK's backwards compatibility policy helps me here :P ). If the ITK
gatekeepers want ManagedITK as part of ITK, I will be happy to help
with this process; if not, I am happy to do my own thing. While the
idea of using gccxml to automagically parse the classes is
interesting, in my mind it will be less work for me to maintain
ManagedITK by hand for the next few years (a nice catch 22).

Regards, Dan