[vtk-developers] Stop using vtkSetObjectMacro

[Michael Halle]

Andy Cedilnik writes:
> In the continuing struggle to make VTK better, I am working on removing
> all use of vtkSetObjectMacro from VTK header files and replace it with
> vtkCxxSetObjectMacro. This will speed-up the compile of VTK and make
> compiler not ran out of memory on some platforms.
>
> In any case, the order of changes is this:
> First we will do Hybrid and Patented, then Rendering, Graphics, Imaging,
> IO, and finally Common. This way changes will be slow and will not mess
> up too many people at the same time.
> ....
> If anybody wants to attack some instances, please do. Make sure to also
> remove the unnecessary #include lines and replace them with class... 

Personally, I'm happy to see VTK compile faster. I just want to point
out that this is another one of those "touch almost every class"
changes that seem to be happening every couple months lately.  Is
there a roadmap or plan for these changes?  Can they maybe be lumped
together a little more?

I understand the logic of changing classes gradually in order to not
mess up ongoing checkouts, but having some VTK classes one way and
some the other leaves developers outside Kitware without any reference
to the "right" way to write a class.  These changes are outstripping
the documentation: there's no way to know the right way to code
without following the email list from day to day or not doing anything
until you can cough up the cash for an updated user's guide (another
issue of mine, of course, but not today's).

On the other hand, I do think it's great that the "old" way will
continue to work. But for how long?  Developers need to know that
information.

I have a suggestion that might help.  Could you document, line by
line, a skeleton vtk class as the canonical "how to write a class"
online document?  This document could be annotated and updated with
proposed and accepted changes so that developers would know the
"right" way as well as providing a history of how the "right" way has
changed.  For example, "In version vtk 4.1, the vtkCxxSetObjectMacro
replaced vtkSetObjectMacro in order to ....  vtkSetObjectMacro will
remain in place through release vtk 4.2."  Porting information could
be maintained here too ("run this script or make these edits to
convert your code").

The person making changes would be responsible for changing the
document to include the proposed changes, the rationale behind them,
and what the impacts are.  That would make it easier for Kitware and
existing developers to review the changes, and easier for new
developers to write their code correctly the first time.


> I wrote a simple Tcl implementation of grep which will help us spot all
> the instances. It is currently tested in Hybrid. After we are done with
> cleaning, it will help us spot new occurrences. 
>
> ctest -R TestSetObjectMacro

This kind of test would be useful as a warning (not error!) measure
during CVS check in.  Lately, I've been thinking that code analysis
tools may be more appropriate than runtime error messages when it's
possible to implement them.  I mean, why should the user get scolded
if he destroys a widget before the underlying window?  It's the
programmer who needs to know about these problems.

Thanks for considering these ideas.

Michael Halle
mhalle at bwh.harvard.edu