[vtk-developers] Proposing vtkObjectMacro

[Marcus D. Hanwell]

On Thu, Sep 13, 2012 at 10:16 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> On Thu, Sep 13, 2012 at 9:53 AM, Kyle Lutz <kyle.lutz at kitware.com> wrote:
>>
>> On Thu, Sep 13, 2012 at 6:48 AM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>> > +1, can we add virtual keyword in front of the ~className()?
>> >
>> > Or are you going to rely on the fact that the parent class has defined
>> > its
>> > destructor virtual (like vtkObject?)
>>
>> The macro is only intended for classes deriving from vtkObject (really
>> vtkObjectBase) so declaring the destructor as virtual would be
>> redundant.
>
> Yes, but in general IMO, it is not a good practice to leave virtual keyword
> out just because base class has declared virtual destructor.  Also implicit
> something is not good unless properly documented. Since we are talking about
> a macro, I don't think its too bad to have virtual keyword in front of the
> desctructor.
>
I am in favor of adding the macro, and disagree with Utkarsh in that
we already have the type macro etc and it will remove the need for a
lot of boiler plate code in each class declaration. I really agree
with Kyle - it is only intended for (and would only work) with
vtkObjectBase derived classes and so the virtual keyword is redundant.

This has bothered me for a long time, and I never found time to write
the macro. I think it would be a great addition, the vtkObjectMacro
was inspired by the Q_OBJECT macro, vtkClassMacro and
vtkAbstractClassMacro sound good to me. We wanted to get consensus on
the common case before extending it to the abstract case.

I think removing PrintSelf would be reasonable, as David states not
all classes will have ivars and the developer of the class must
implement the function body as Utkarsh pointed out.

My $0.03.

Marcus