[vtk-developers] Stop using vtkSetObjectMacro

[Andy Cedilnik]

On Mon, 2002-05-13 at 14:35, Michael Halle wrote:
> 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?

Well, I would agree with you, but some of these changes do not require
API to change. For example, this change most people who use VTK classes
properly will not even notice. Some projects however rely on the fact
that if you include one VTK class you get another one and they will have
to be modified.

> 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 do not plan to remove the "old" way, because it is perfectly valid
way. The only problem with the "old" way is that it makes includes too
big for "some" compilers. That is why it should be eliminated for VTK
classes since they are on the top of the hierarchy.

> 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").

This is sort of on my list. I was also planning to write a small test
that traverses through a vtk header file and checks for certain
properties such as that superclass matches, that there are empty copy
constructor and assignment operator, that constructor and destructor are
empty and so on.

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

That I agree with.

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

The user never sees this messages unless he runs ctest. This tests are
all TCL based and are done on the source code.

However, the runtime messages should go somewhere. Look at just about
any software. It reports errors to user not to developers. Except
programs like Mozilla with its talkback.

			Andy Cedilnik