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

[Will Schroeder]

A couple of points:

+ there is a drift in the meaning of the API. 22 years ago as C++ was
emerging some of the semantics were less settled. Insert meant "put data
here and perform memory allocation if necessary" as compared to Set which
meant "put data here without range checking." Things have evolved since
then, probably for the better, which is why the behavior sometimes feels
weird given a contemporary understanding.

+ 'that renaming an API qualifies as "minimal disruption"' - well that's
easy for a developer to say :-). And frankly I'm less concerned about
developers than I am about users and paying customers.

+ Since, based on the email response, it seems that several of us have
jumped right back to the attitude of  "....but I want to polish some code!"
how about we strike a deal: before any more polishing each of you speed up
one algorithm by 2x or more (yes you can use vtkSMPTools or other
approach), or add a new class with a new analysis, visualization or
rendering feature. Then I know you are serious about balancing the needs of
capability versus polish :-) Call me when you are done, or if you need some
ideas I can steer you.

Best, and thanks for humoring me,
W

On Thu, Mar 24, 2016 at 1:19 PM, David Lonie <david.lonie at kitware.com>
wrote:

> 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
>



-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e4563791/attachment-0001.html>