[vtk-developers] More wrapper stuff

[David Gobbi]

On Fri, May 21, 2010 at 12:35 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Thu, May 20, 2010 at 11:14 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> I've been playing around with the lex/yacc parser front-end to the
>> wrappers.  At this point, I have a version that can parse all of the
>> VTK class header files, including the parts that used to be blocked
>> off by //BTX, //ETX.
>
> This sounds great, especially if we could get rid of the BTX/ETX blocks, and
> being able to wrap enums would allow us to improve type safety. Could we
> then use those enum types in function declarations, and call that from all
> wrapped languages?

I only plan to save to save the enums as named integer constants.
Using enum types for argument types would make the wrapping process
more difficult, so I recommend that you stick to ints and anonymous
enums.  If Kitware switched over to named enums universally, then I
might put forth the effort, but it is way to much work to do it for
the sake of a few new classes.

>> It's all based on the original VTK wrapper lex/yacc parser, just
>> cleaned up a bit and beefed up substantially. If anyone wants to play
>> with it, I have a VTK-to-XML converter at
>> http://github.com/dgobbi/WrapVTK.  Eventually I'd like to get it to
>> store enum and template info in the FileInfo structure but I have no
>> timeline for that... my main goal here was to get it to parse more of
>> the header files and eliminate the need for //BTX //ETX.
>
> This sounds very promising. I will try to make some time to look through
> this, it sounds like you are adding quite a few things from my own personal
> wishlist. I would like to make a topic branch with your changes in it, see
> how well they test out with all of the wrapped languages.
> One thing I am not entirely clear on - is this support for all three wrapped
> languages, or some subset of them? If it is not for all three, do you have a
> feeling for how difficult it would be to extend it?

All three use the same parser as a front-end, so the BTX/ETX fix is
valid for all three (I hate BTX/ETX).

In terms of enums, special types like vtkVariant, unicode, operators,
templates, etcetera I'm only extending the Python wrappers.

I test the Java and Tcl wrappers regularly to make sure that my
changes to the parser don't break them, but I'm not extending them
except for doing small fixes where necessary.  Adding proper
vtkStdString support, for example. The difficulty level for adding new
features to the Tcl and Java wrappers depends a lot on how familiar
people are with the C APIs for Tcl and Java.  Simple things like
adding vtkUnicodeString support should only take a few hours.  Things
like adding universal support for special types would take a few
weeks.

  David