<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 23, 2015 at 5:51 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi David,<div><br></div><div>It's apparent to me that part of the difficulty surrounding this change is</div><div>due to the name of the method.  Why not use a new name?</div><div><br></div><div>bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]);</div><div><br></div><div>I confess that I have an ulterior motive.  I like all Get() or Set() methods</div><div>to get/set a property that depends only on the the object itself.  Here,</div><div>the Bounds depend on both the object and on a second object.  So I</div><div>don't consider this method to be a "getter" in the strict sense, hence</div><div>"ComputeBounds" rather than "GetBounds".</div><div><br></div><div>Basically, I like it when Get methods are associated with properties/traits</div><div>of the object.  Eventually, VTK's wrappers might associate Set/Get</div><div>methods with Python properties.  In fact, this idea can already be seen</div><div>in action in tvtk, Enthought's Traited VTK.</div></div></blockquote><div><br></div><div>Hmm, and this also wouldn't require the 'using' wrapper support right away...I like it! The distinction between Get/Compute makes sense.</div><div><br></div><div>The name is a bit long, and "ForViewport" is implied by the arguments. I'd like ComputeBounds, but that's already a virtual on many of these classes.</div><div><br></div><div>Now I'm leaning towards</div><div><br></div><div>vtkBoundingBox ComputeBoundingBox(vtkViewport *)</div><div><br></div><div>That would also:</div><div>- eliminate the output-array-arg issues with the Tcl wrappers (Yay!)</div><div>- encourage use of the vtkBoundingBox class, which is a really nice API for working with a bounding box that leads to much, much more consistent and readable usage (there are a few approaches used for, e.g. invalid bounds, that aren't always consistent).</div><div><br></div><div>It needs a couple hints to be wrapped properly, but that's not nearly as much trouble :)</div><div><br></div><div>Dave</div><div><br></div><div><br></div></div></div></div>