[Insight-developers] [ITK + Python] Wrapping classes proposal

[William A. Hoffman]

At 11:35 AM 6/10/2005, Benoit Regrain wrote:

>Second question: CableSwig versus Swig ?
>----------------------------------------
>
>I would like to know what is today the advantage of CableSwig ? 
>(as opposed to Swig)
>
>I understand the historic choice, when Swig didn't handle template classes.
>But Swig evolved and is now able to handle template classes (and
>nested classes, though their appear to still be some kind of limitations on
>heavily nester classes, as I understand it).
>What is now the CableSwig additional value compared to Swig ? Does
>CableSwig add any special wrapping features for ITK ? [e.g. by adding or
>removing some specific methods or any other ITK specific reason]  ?
> 
>Other informations for ITK :
>----------------------------------------
>
>If the ITK-Kitware folks are interested to work on this subject, I would
>be deligthed to try to provide some help and feedback... since I need
>this feature bad [ I'm a VTKPython drug addict: please help to switch
>...to ITKPython ;-] .
>
>    Yours,
>    Benoit Regrain
> 

I can address this question.  Swig does not provide a full
c++ parser and is incapable of parsing all ITK template classes
fully.   If you could get the same wrapping working with some
future version of swig, that would be great.  However, I don't think
you will be able to, but you never know, feel free to try.

Also, swig is not really meant to wrap libraries, but rather smaller
pieces of code.   So CableSwig is also providing some functionality
to make wrapping libraries of code easier.   Swig requires that you tell
it the state of each class referenced.  (Is it wrapped by swig?  If so
where is the module that wrapped it?)   The .idx files produced by
CableSwig handle this.    

So, there are two current reasons for CableSwig, parsing, and wrapping
multiple modules of related classes. 

As for the inconsistencies in the name mangling, those should most likely
be fixed, but since they are hand generated, my guess is they will go bad
over time.   Brad King has talked about an approach where we start to use
manual instantiation in ITK, and link that to the wrapping process.  If we
went to that approach things might be more consistent.

There is one other issue to think about, and that is that while your approach
may work for python, it would make python inconstant with java and tcl.  Also,
it really does not instantiate new templates, the classes have to be wrapped,
so to me it seems like a lot of work for a bit of syntactic sugar.  If you try
and use a class that is not wrapped, I assume it dies.


It comes down to this:
     1 reader=itk.itkImageFileReader_New(ITK_US,2)
     2 reader.SetFileName("Data/homersbrain.bmp")
     3 img=reader.GetOutput()
    

Verses this:
     1 reader=itkImageFileReaderUS2_New()
     2 reader.SetFileName("Data/homersbrain.bmp")
     3 img=reader.GetOutput()
   
Or c++:
     itkImageFileReader<itk::Image<unsigned short,3> >::Pointer r =  
        itkImageFileReader<itk::Image<unsigned short,3> >::New();
     r->SetFileName("Data/homersbrain.bmp");
     itk::Image<unsigned short,3>::Pointer img = r->GetOutput();


To me both python versions are about the same distance from the C++.
Do you specify the template parameters as arguments or part of the name?
What are the benefits of specifying them as arguments?

-Bill