[vtk-developers] Tcl wrapping and output array arguments

[David Lonie]

On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie <david.lonie at kitware.com>
>>> wrote:
>>>
>>>> 2) If so, how can I teach the wrappers about it?
>>>>
>>>
>>> Adding things like this to Tcl is easier than for Java or Python, but
>>> it's more than an afternoon's work.
>>>
>>
>> One more thing:
>>
>> If you know offhand, can you briefly outline the steps that are needed to
>> do this? That might help clarify whether the maintenance burden is
>> excessive or not. Would it be a one-time deal that would teach Tcl how to
>> wrap all similar methods, or would it need to be repeated for every similar
>> method that gets added?
>>
>
> My brief outline is this: find the code in vtkWrapTcl.c that builds arrays
> to be used as return values, and then do something similar for this new
> kind of method signature, except have it assign a global name (whatever
> name was passed as a parameter) to the new array instead of returning it.
> If it is done for this method, it should work for all similar methods.
>

This seems more doable than I'd feared, since it'd be a generic approach
that should "just work" for similar cases.

It sounds like there's a lot of support for removing Tcl, but it's unlikely
that we'll see it go away completely anytime soon for a multitude of
reasons. So back to the immediate issue of how the GetBounds change can be
made to work with the wrappers, I see three options:

1) Train the wrappers to understand it. Might not be worth the effort if
we're planning to pull support soon.

2) Add an additional non-deprecated GetBounds signature

double* GetBounds(vtkViewport*)

I don't like this approach as it has issues thread safety, and requires
each object to carry around an array just to pass results back to a caller
-- a pattern we should be moving away from. I'd be more supportive of this
approach if we decided to use vtkTuple<double, 6> instead of double*, but
this would also be likely to require some significant wrapper training
and/or concrete vtkTuple subclasses.

3) Begin a long-term deprecation of Tcl. We'll not plan on removing it
completely anytime soon, but enabling Tcl wrapping will also require
enabling legacy code in VTK. This way the old legacy GetBounds, etc
signatures will still be available to Tcl, and feedback from the
deprecation would help us understand the full impact of completely removing
Tcl, as we'll grab the attention of users that might not follow the mailing
lists.

My vote is for 3 -- it's an easy change that gives people a heads-up about
then inevitable future removal of Tcl support, and ensures that everything
will "just work" for legacy code until we decide to completely pull the
plug.

Thoughts? Votes? Alternatives?

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150323/af851656/attachment.html>