[vtk-developers] Tcl wrapping and output array arguments

[Berk Geveci]

+1

On Mon, Mar 23, 2015 at 6:12 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> +1
>
>
> 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[6]);
> >
> > 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>
> > wrote:
> >>
> >> 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
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at:
> http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150323/3cdf7915/attachment.html>