[vtk-developers] Templated filters

[David Gobbi]

On Tue, Feb 9, 2010 at 6:17 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
>
>
> On Mon, Feb 8, 2010 at 4:36 PM, Timothy M. Shead <tshead at sandia.gov> wrote:
>>
>> 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.
>
> I agree 100%.

I see, and now I can comfortably say that I also agree.  For me, there
is a huge distinction between adding new features "along the lines of
Boost.Python" vs. replacing the existing wrappers.

It is completely reasonable to use an alternative wrapping scheme to
wrap objects that are not derived from vtkObjectBase.  With a bit of
fixing, it would even be possible to modify vtkParse.h et al. to make
it recognize a finite number of these additional objects as method
parameters.

   David