[vtk-developers] Recent API changes

Berk Geveci berk.geveci at gmail.com
Fri Jan 13 10:34:54 EST 2006 

I would also like to point out that some of the changes that cause
breaks are due to new policies that VTK developers have adopted in
time.

One of these is limiting the number of header files included by other
header files, specially the ones that are included by a lot of other
implementation files. There was a painful clean-up where a lot of
unnecessary includes were removed and a lot of code broke (and fixed
easily by adding the appropriate includes). At the end, the
compilation time of VTK improved and some unnecessary
interdependencies were removed. And because of this, it is now assumed
that if you are using a class, you will include it's header file.

It looks like, in this case, vtkFieldData was including vtkDataArray.h
because it uses it in inline methods. Utkarsh changed this to be a
vtkAbstractArray.h because the inline methods now use vtkAbstractArray
(which is the superclass of vtkDataArray). Any code that uses
vtkDataArray should include vtkDataArray.h and not assume that it can
get it from vtkFieldData.h. So a side effect of what Utkarsh did is to
force other applications to follow one of the VTK guidelines: include
a header file of a class you use.

I agree that in this case changing the include to be vtkDataArray.h
has little cost and will save application developers time when they
are porting to VTK 5.2. The point I am trying to make is that
sometimes we intentionally break backwards compatibility by
introducing new guidelines or bringing VTK up-to-date. I can think
quite a few changes that happened over the last years that forced
people to change their code:
* imaging pipeline and as a side effect deprecation of vtkStructuredPoints
* pipeline changes to support streaming and distributed processing
* directory restructuring
* changing the build process to use CMake
* changing the testing process to use Dart
* moving all the attributes to vtkFieldData and making
vtkDataSetAttributes a sub-class of vtkFieldData
* the recent pipeline rearchitecturing

Some of these were developed for ITK and adopted by VTK because it was
the right thing to do. ITK development team had the luxury of
designing a modern system from scratch whereas the VTK development
team had to bite the bullet and make the improvements at the cost of
breaking backwards compatibility. Without the imaging pipeline, VTK
would have a lot fewer users. Without the distributed data support,
there would be no ParaView. The list goes on and on. I am sure there
will be plenty more of these in the future. It is the only way to move
VTK forward. I support a backwards compatibility policy as long as it
does not choke development and innovation.

-Berk


On 1/13/06, David Cole <david.cole at kitware.com> wrote:
> I'm all for backward compatibility; don't get me wrong...
>
> I'm of the opinion that it is an extremely important feature of software
> *releases*. So, for example, I would expect that the VTK 5.0 branch is
> very largely backward compatible with VTK 4.4. Any incompatibilities
> should be documented, obvious and easy to workaround. If that's not the
> case, I would expect emails here disucussing the issues or bug reports
> to the VTK bug tracker.
>
> But I also think it's a lot to expect of a project that still has active
> development occurring on it to be 100% backwards compatible 100% of the
> time. A cvs repository where commits are happening is inherently an
> entity that's changing and fluctuating. Developers are likely to
> introduce an incompatibility simply by mistake once in a while. A
> stable, known snapshot that is known to be backwards compatible is more
> appropriate for customers/developers that demand stability...
>
> Again, just my friendly opinion, :-)
> David
>
> Lorensen, William E (GE, Research) wrote:
>
> >David,
> >
> >Obviously, we have different ideas about the importance of backward compatibility. Something as harmless a removing an include file can cause major impact on customers outside the development community.
> >
> >We have some nightly builds of InsightApplications that build against the nightly VTK tree. We do this so that we can detect VTK API changes as soon as they occur. One of our challenges is that InsightApplications must build against the stable VTK 4.4 and the nightly VTK trees.
> >
> >There is a great article at
> >http://onlamp.com/lpt/a/5626 that discusses backward compatibility.
> >
> >On a related note, The Insight Software Consortium is formulating a policy on backward compatibility. It is currently in the draft stage, but soon we will open up discussion to the itk and vtk communities.
> >
> >Bill
> >
> >
> >-----Original Message-----
> >From: David Cole [mailto:david.cole at kitware.com]
> >Sent: Thursday, January 12, 2006 4:22 PM
> >To: Utkarsh Ayachit
> >Cc: Lorensen, William E (GE, Research); Bill Lorensen;
> >vtk-developers at vtk.org
> >Subject: Re: [vtk-developers] Recent API changes
> >
> >
> >There is little harm in keeping a single #include. However, if we must
> >always keep all #includes then they will always accumulate over time and
> >never get cleaned up even when they are no longer necessary or have been
> >replaced by something better. Projects that don't weed out the
> >unnecessary #includes compile slower and slower over time even while
> >computing power is still increasing.
> >
> >I think most developers understand the risks of developing against the
> >HEAD of any CVS project. Folks that need stability should be snapped to
> >a branch point or using a code base that remains stable by some other
> >mechanism.
> >
> >Just my opinion, of course... :-)
> >David
> >
> >Utkarsh Ayachit wrote:
> >
> >
> >
> >>Yes, may be you are correct. I didn't realize the impact of this change
> >>given that it's assumed that people include the headers for the classes
> >>they use in the .cxx file. However, if the consensus is otherwise, I
> >>have no qualms in adding the header file. I again, apologize for the break.
> >>
> >>Utkarsh.
> >>
> >>Lorensen, William E (GE, Research) wrote:
> >>
> >>
> >>
> >>
> >>>Usually there is little harm in keeping a #include. Trade this off with breaking code in the installed base.
> >>>
> >>>Thanks,
> >>>
> >>>Bill
> >>>
> >>>-----Original Message-----
> >>>From: vtk-developers-bounces+lorensen=crd.ge.com at vtk.org
> >>>[mailto:vtk-developers-bounces+lorensen=crd.ge.com at vtk.org]On Behalf Of
> >>>Wylie, Brian
> >>>Sent: Thursday, January 12, 2006 3:39 PM
> >>>To: Bill Lorensen; vtk-developers at vtk.org
> >>>Subject: RE: [vtk-developers] Recent API changes
> >>>
> >>>
> >>>Bill,
> >>>
> >>>Not sure about the exclusion of that specific header file. Utkarsh will
> >>>have to look into it. But I just wanted to give a general apology about
> >>>the break, Kitware is doing this work under the direction of Sandia to
> >>>support information visualization applications. Obviously we will try to
> >>>minimize the impact of the changes as much as we can.
> >>>
> >>>Best regards,
> >>>
> >>> Brian Wylie - Org 9227
> >>> Sandia National Laboratories
> >>> MS 0822 - Building 880/A1-J
> >>> (505)844-2238 FAX(505)845-0833
> >>>      ____                  _    __
> >>>     / __ \____  _________ | |  / (_)__ _      __
> >>>    / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
> >>>   / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
> >>>  /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/
> >>>
> >>>                                   Unleash the Beast
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: vtk-developers-bounces+bnwylie=sandia.gov at vtk.org
> >>>>[mailto:vtk-developers-bounces+bnwylie=sandia.gov at vtk.org] On
> >>>>Behalf Of Bill Lorensen
> >>>>Sent: Thursday, January 12, 2006 1:06 PM
> >>>>To: vtk-developers at vtk.org
> >>>>Subject: [vtk-developers] Recent API changes
> >>>>
> >>>>Folks,
> >>>>Last week,  after a number of changes enhancing vtkDataArray,
> >>>>some of our itk code stopped compiling. I believe it is
> >>>>because itkDataArray.h is no longer being included by some
> >>>>other class.
> >>>>
> >>>>Was this an intentional change? What is the rationale? These
> >>>>sorts of API changes are troublesome.
> >>>>
> >>>>Bill
> >>>>
> >>>>_______________________________________________
> >>>>vtk-developers mailing list
> >>>>vtk-developers at vtk.org
> >>>>http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>vtk-developers mailing list
> >>>vtk-developers at vtk.org
> >>>http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>_______________________________________________
> >>>vtk-developers mailing list
> >>>vtk-developers at vtk.org
> >>>http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>vtk-developers mailing list
> >>vtk-developers at vtk.org
> >>http://www.vtk.org/mailman/listinfo/vtk-developers
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>

More information about the vtk-developers mailing list