[Insight-developers] [ITK + Wrapping (Python)] Wrapping classes proposal - V.3

[Brad King]

Benoit Regrain wrote:
> Concerning this patch, I would now :
> - if ITK is interested by that, and integrate it
>   (thus, I will continue and write the wrap_Xxx.cmake
>   files for other ITK parts)
> - if there have conceptual or other problems with this proposal
>   (for each of 2 points)

Certainly we will consider putting this in ITK because it will be useful 
to others and is essentially attempting to do what we have not had time 
to do ourselves.  Thanks for your efforts so far.

There are a few things with which we must deal before this work will be 
ready for inclusion in ITK proper:

1.) It will have to be updated for the CVS version of ITK because we do 
not want to make such large changes in a release branch.

2.) Whatever changes are made must be tested with Tcl and Java wrapping 
as well.  The wrapper configuration files are shared among the languages.

3.) We'd like to avoid making changes to python.cxx in the CableSwig 
sources.  There are two reasons for this.  First we do not want the 
sources to deviate from the original SWIG versions so that we can 
upgrade the internal SWIG version at any time.  Second we want 
consistency among the wrappers for the different languages.  If special 
support is added to CableSwig for python an equivalent should be made 
available for the other languages (if it makes sense for them too).

Note for #3 that you are free to propose changes to the non-SWIG part of 
CableSwig.  This might help you do things with CableSwig that require .i 
file features in native SWIG.

> ---> Presentation of changes (from the ITK project v2.0.1) :
> 
> 1 - Use of CMake to generate wrapping :
> ------------------------------------------
> All wrap_Xxx.cxx files are directly generated by CMake.
> For :
> - There is no enought C++ macros (that are numerous and
>   copied between some files... ex : All Transform classes wrapping)
> - All classes are wrapped with consistent rules. The mangled
>   name is then coherent between all classes
> - It simplifies the integration of the second point (Tree of
>   templated classes)
> - The itkCSwigMacro.h and itkCSwigImage.h files are now useless...
>   Thus, it's easier to wrap personal ITK classes without integrate them
>   in the ITK folder tree.
> - Best support for future ITK addons

These are all good arguments, IMO.

> Against :
> - The mangled name isn't kept...

I'm not too worried about this (though other developers may have a 
different opinion).

> For certain classes used to define the template of other classes, it may be
> good to have a consistant mangled name. These class's wraps are in the
> CSwig/WrapTypePrefix.cmake file.
> For other classes, the mangled name can be choosed randomly.
> 
> 
> The write of these files is made using CMake macros. These macros
> are in CSwig/WrapITK.cmake
> The CSwig/WrapType*.cmake files are help  for the basic types and
> advanced types creation. These types are used define the template
> classes.
> In CSwig/Common : all wrap_Xxx.cxx files are replaced by
> wrap_Xxx.cmake when it's needed
> 
> 
> 2 - Tree of templated classes :
> -------------------------------
> The goal is to have a simplest and generic use of templated ITK classes.
> Consider this python example :
>   def write( itkImg, file ) :
>      # typedef itk::ImageFileWriter< itkImg::Self > writerT
>      writerT = itkImageFileWriter[ itkImg ]
>      writer = writerT.New()
>      writer.SetInput( itkImg )
>      writer.SetFileName( file )
>      writer.Update()

This is a great motivating example.  Since your proposed implementation 
is purely in python (and does not require SWIG support), I don't have a 
problem with adding it even if equivalents for the other languages 
cannot be found.  This feature does not prevent users from choosing the 
instantiations themselves (the old way).

-Brad