I wholeheartedly agree.  I've run into similar problems with the

recent changes to the filters that removed the "SetInputScalars" in

favor of the more generic "SetInputArrayToProcess", and it's mostly

undocumented syntax.  and again with the vtkKitwareContourFilter

vanished, with it's functionality absorbed into the generic

vtkContourFilter, but nothing was said about this on the website, the

TWiki (that i've been able to find), or the mailing lists.<br>

<br>

It would be great if these changes were all documented somewhere in a

"VTK4.4 to CVS Changes" document.  Even better, it would be great

if such changes were "phased in", eg Make SetInputScalars simply call

SetInputArrayToProcess, and print a "Warning: This method is

deprecated, please use SetInputArraytoProcess with the following

arguments: blah blah".  It makes it really hard to use VTK when

the syntax & rules change to incompatible forms so often.<br><br><div><span class="gmail_quote">On 6/2/05, <b class="gmail_sendername">Michael Halle</b> <<a href="mailto:mhalle@bwh.harvard.edu">mhalle@bwh.harvard.edu

</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello,<br><br>I've recently been developing and testing some code<br>using the CVS version of VTK.  In my testing, I found

<br>that one of the method names for a class I wrote,<br>vtkLightKit, had been changed for "for naming<br>consistency" as the CVS logs say.<br><br>The details, which aren't incredibly important,<br>involve the naming of lights.  LightKit has a key light,

<br>a fill light, several back lights, and a headlight.  When<br>I wrote the module, I called the lights KeyLight, FillLight,<br>BackLight, and Headlight.  Headlight wasn't HeadLight<br>because "headlight" is an English word, and BackLight wasn't

Backlight because several discrete "back lights" form the "backlighting" of the scene.  Was this the best choice? Certainly debatable, but I was the author and I made the choice based on at least some rational thought.

<br><br>Recently, Mathieu Malaterre did some code cleaning and<br>changed Headlight to HeadLight for consistency.  While<br>I understand the decision to do so (I love consistent<br>code names too, and I'm not necessarily wedded to

<br>my way anyway), this is an API change based on aesthetics<br>that breaks compatibility with existing code.<br>vtkLightKit isn't the most widely used module, but it has<br>been in vtk since 4.0, and this change wasn't<br>

really required for anything other than aesthetics. As potentially important as these kind of changes are for the usability of the system, it's really important to keep in mind that these kind of changes break other people's code.

<br>There are various ways to deal with it (backwards compatibility<br>synonyms, for example), but at the very least it would<br>be useful for outside developers to have a list of these<br>kind of changes to help with the porting process from one

release to the next. Again, let me stress that the bigger issue is far more important to me that this relatively minor example of it. Could Kitware establish and promote a consistent policy on API changes?

<br><br>Thanks.<br><br>Michael Halle<br><a href="mailto:mhalle@bwh.harvard.edu">mhalle@bwh.harvard.edu</a><br><br><br>_______________________________________________<br>vtk-developers mailing list<br><a href="mailto:vtk-developers@vtk.org">

vtk-developers@vtk.org</a><br><a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br></blockquote></div><br><br><br>-- <br>Randall Hand<br><a href="http://www.yeraze.com">

http://www.yeraze.com</a>