[vtk-developers] Tcl wrapping and output array arguments
bill.lorensen at gmail.com
Mon Mar 23 18:12:25 EDT 2015
On Mon, Mar 23, 2015 at 2:51 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi David,
> It's apparent to me that part of the difficulty surrounding this change is
> due to the name of the method. Why not use a new name?
> bool ComputeBoundsForViewport(vtkViewport *, double bounds);
> I confess that I have an ulterior motive. I like all Get() or Set() methods
> to get/set a property that depends only on the the object itself. Here,
> the Bounds depend on both the object and on a second object. So I
> don't consider this method to be a "getter" in the strict sense, hence
> "ComputeBounds" rather than "GetBounds".
> Basically, I like it when Get methods are associated with properties/traits
> of the object. Eventually, VTK's wrappers might associate Set/Get
> methods with Python properties. In fact, this idea can already be seen
> in action in tvtk, Enthought's Traited VTK.
> - David
> On Mon, Mar 23, 2015 at 9:18 AM, David Lonie <david.lonie at kitware.com>
>> On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi <david.gobbi at gmail.com>
>>> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie <david.lonie at kitware.com>
>>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi <david.gobbi at gmail.com>
>>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie <david.lonie at kitware.com>
>>>>>> 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
>> Thoughts? Votes? Alternatives?
> Powered by www.kitware.com
> Visit other Kitware open-source projects at
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> Follow this link to subscribe/unsubscribe:
Unpaid intern in BillsBasement at noware dot com
More information about the vtk-developers