<br><br><div class="gmail_quote">On Mon, Feb 8, 2010 at 4:36 PM, Timothy M. Shead <span dir="ltr"><<a href="mailto:tshead@sandia.gov">tshead@sandia.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">David Gobbi wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In other words, if you really want to write new wrappers, what's stopping you?<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<br>

<br>
vtkVariant is a commonly-used class that's unwrappable, leaving gaps for users of scripting languages.<br>
<br>
vtkTypedArray, vtkDenseArray, and vtkSparseArray are templated on type, and currently unwrapped.<br>
<br>
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.<br>

</blockquote></div><br>I agree 100%.<br>