<div dir="ltr">A couple of points:<div><br><div>+ 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.</div></div><div><br></div><div>+ '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.</div><div><br></div><div>+ 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.</div><div><br></div><div>Best, and thanks for humoring me,</div><div>W</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 1:19 PM, David Lonie <span dir="ltr"><<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Mar 24, 2016 at 12:42 PM, Will Schroeder <span dir="ltr"><<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div></span><span class=""><div class="gmail_extra">I'd like to see more cycles go into algorithms, computing, and performance.</div></span></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>My $0.02,</div><div>Dave</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div>
</div>