[vtk-developers] About the vtkDataArray::InsertTuple() method

[David Lonie]

On Thu, Mar 24, 2016 at 12:42 PM, Will Schroeder <will.schroeder at kitware.com
> wrote:

> I think there is sometimes a tendency to get caught up in too much
> polishing and software process and forget core algorithmic and performance
> concerns.
>
> I'd like to see more cycles go into algorithms, computing, and performance.
>

This rings true and I certainly agree that a stable API is a great thing to
offer to customers. However, IMO this should be balanced with providing a
'correct' API that makes sense and is intuitive and frustration-free as
possible.

I wouldn't consider revamping the Insert behavior (or just removing the
method) to be polish -- I'd consider it a bugfix. Array insertion has a
well-defined meaning to developers, and this break from convention is a
problem for new developers.

They'll expect insert to insert, but instead it just sets. Their code looks
correct, and they'll have a hell of a time trying to figure out why it
isn't working at runtime until they either (a) start digging through
documentation for what should be self-documenting APIs, or (b) step through
the code with a debugger. At this point, they've wasted time tracking down
this unconventional behavior just to find that VTK's methods don't behave
as expected. It's incredibly frustrating to review your own code countless
times trying to figure out what you did wrong, when in reality it's an
external toolkit that's broken -- and it's worse when the brokenness is
known and intentional.

To play devil's advocate to the 'stable APIs keep customers happy"
argument, broken APIs discourage new developers. It doesn't inspire
confidence in the toolkit when you can't expect a common array method to do
what it says it should.

My $0.02,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/a4ed5435/attachment.html>