[vtk-developers] Proposing vtkObjectMacro

[Utkarsh Ayachit]

I really don't see the point. If anything, it would be good to do what
Qt does to provide macro to disable copy constructor similar to
Q_DISABLE_COPY(class). I cannot use vtkClassMacro() for abstract
classes anyways. And I reiterate, hiding constructor/destructor is
just plain  *weird*.  But this isn't a battle I am willing to fight.
So if members of the VTK ARB agree, I have rescind my concerns.

Utkarsh


On Thu, Sep 13, 2012 at 11:15 AM, Kyle Lutz <kyle.lutz at kitware.com> wrote:
> 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
>>
>>
> _______________________________________________
> 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
>