[vtk-developers] Templated filters

[Timothy M. Shead]

David Gobbi wrote:

> In other words, if you really want to write new wrappers, what's stopping you?

The current auto-generated wrappers work fine for 95% of what we're 
doing with VTK, so I don't advocate throwing it all away for the last 
5%.  What I'd like to see is a hybrid world in which wrapping would have 
minimal impact on the design of the API.

For example, vtkGraph has two overloaded versions of GetInEdge(), one 
that returns vtkInEdgeType (not wrappable), and one that takes 
vtkGraphEdge (wrappable) as an argument.  There are several other 
methods that have this suboptimal split-personality.

vtkVariant is a commonly-used class that's unwrappable, leaving gaps for 
users of scripting languages.

vtkTypedArray, vtkDenseArray, and vtkSparseArray are templated on type, 
and currently unwrapped.

Ideally, I'd like to see a mechanism to support explicit wrapping of 
classes that are templated / classes that don't derive from vtkObject. 
This would require extra effort from the programmer, along the lines of 
Boost.Python or SWIG, but would supplement - rather than replace - the 
current auto-generated wrappers.

Will Schroeder wrote:

> 1) somebody somewhere has to decide which templates are to be
> instantiated, in ITK we generally choose many native types (e.g.,
> char, short, long, float, double, etc.) and 2 and 3 dimensions. When
> wrapped this created massive libraries.

> 2) the wrapped classes end up
> having awful names reflecting their instantiation choices, e.g.
> itkOtsuThresholdImageCalculatorUS3 (US3 meaning unsigned short, 3
> dimensions).


Point well taken, although I'd argue that VTK is doing the same thing, 
to a lesser degree - vtkDataArrayTemplate is simply being "hidden" 
behind a set of officially-sanctioned array types: vtkDoubleArray, 
vtkIdTypeArray, etc.

Cheers,
Tim