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

[Benoit Regrain]

Hi,


----- Original Message ----- 
From: "William A. Hoffman" <billlist at nycap.rr.com>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>;
<insight-developers at itk.org>
Sent: Friday, June 10, 2005 6:05 PM
Subject: Re: [Insight-developers] [ITK + Python] Wrapping classes proposal


>>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]  ?
>>

> 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.
I haven't made so many tests with swig, but it was to know the difference
between them. Could you tell me the name of each classes that provide
problems while a wrapping by swig (to see their content) ?




> 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.
I don't know enough in Java or Tcl to know if my wrapping proposal is
possible in these languages. But this proposal may be a adjunction
without removing the actual use, and offer an use nearest to C++.

Yes, if I try to use a non-wrapped class, an exception is raised.
And then the user may make a cast to obtain an other type that
is wrapped



> 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?

Consider a function creating a piece of ITK pipeline. For example, this
pipeline will write the image passed as input.

In C++ :
template<class T,int dim>
void Write(itk::Imagedata<T,dim> *img, const char *name)
{
    typedef itk::ImageFileWriter<img::Self> WriterType;

    WriterType::Pointer *writer = WriterType::New();
    writer->SetInput( img );
    writer->SetFileName( name );
    writer->Update();
}

In Python :
def Write( img, name):
    writer = itk.ImageFileWriter_New(img)
    writer.SetInput( img )
    writer.SetFileName( name )
    writer.Update()

Without considering all problems of image types wrapped, we can have a
function that is independant to the input image type. If we don't have that,
we are obliged to make the good cast before calling the function.
And calling the good cast before each call to a function like
in the above example, can reduce the results (and the speed)
of the program.

Cheers
Benoit Regrain