[vtk-developers] Proposing vtkObjectMacro

[Kyle Lutz]

Alright, I've made the following changes and re-pushed the topic:

1. Rename vtkObjectMacro() to vtkClassMacro()
2. Remove the PrintSelf() declaration.

Thanks for all the feedback so far!

-kyle

On Thu, Sep 13, 2012 at 8:09 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> +1 from me. I prefer vtkClassMacro.
>
>
> On Thu, Sep 13, 2012 at 11:01 AM, Robert Maynard
> <robert.maynard at kitware.com> wrote:
>>
>> +1 I fully support any reduction in the amount of boilerplate code in each
>> VTK class header, and this also decreases the number
>> of mistakes that developers have while writing new classes.
>>
>>
>> On Thu, Sep 13, 2012 at 10:58 AM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>>
>>> 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
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>
>>
>>
>> --
>> Robert Maynard
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>