[vtk-developers] Proposing vtkObjectMacro

Thu Sep 13 15:22:35 EDT 2012

Since it is a real pain when vtkSetGet.h is changed (at least for old guys
with slow machines),  why not add vtkAbstractClassMacro now?

On Thu, Sep 13, 2012 at 3:12 PM, Kyle Lutz <kyle.lutz at kitware.com> wrote:

> Thanks all for the input.
>
> For now I'd like to keep the discussion targeted at vtkClassMacro(). A
> macro for abstract classes (which VTK has far fewer of) could be added
> later if vtkClassMacro() proves useful. Furthermore, I don't really
> think using a vtkDisableCopy() type macro is the proper way to
> prohibit copying of VTK classes. vtkObjectBase should just declare its
> copy constructor and assignment operator as private a la
> boost::noncopyable (but this is a larger change than I feel
> comfortable making).
>
> I've re-pushed the topic with the constructor and destructor
> declarations removed. Now the documentation looks like this:
>
> // Description:
> // Declares a vtkObject subclass.
> //
> // Notably, performs the following actions:
> //   - invokes the vtkTypeMacro()
> //   - disables its copy constructor and assignment operator
> //   - declares its static *New() method
> #define vtkClassMacro(className, parentClassName)
>
> -kyle
>
> On Thu, Sep 13, 2012 at 11:49 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > That much wasn't clear to me in the other suggestions. I would like to
> > see a vtkClassMacro and vtkAbstractClassMacro, and thought that was
> > what was being converged on.
> >
> > On Thu, Sep 13, 2012 at 2:44 PM, Utkarsh Ayachit
> > <utkarsh.ayachit at kitware.com> wrote:
> >> I am suggesting the vtkDisableCopy() macro as an alternative to the
> >> vtkClassMacro() since after stripping out the controversial parts for
> >> vtkClassMacro() all that remains is disable copy, vtkTypeMacro() and
> >> New() and frankly, New() is also not always needed since it doens't
> >> work for abstract classes.
> >>
> >>
> >> On Thu, Sep 13, 2012 at 2:40 PM, Marcus D. Hanwell
> >> <marcus.hanwell at kitware.com> wrote:
> >>> Why provide a disable copy macro when it is a requirement of vtkObject
> >>> derived classes? It should just be part of the vtkClassMacro, with
> >>> QObject derived classes they can have copy constructors, and so
> >>> provided an option makes more sense there.
> >>>
> >>> On Thu, Sep 13, 2012 at 2:29 PM, Aashish Chaudhary
> >>> <aashish.chaudhary at kitware.com> wrote:
> >>>> +1 to remove construct and destructor. Also I think like Qt we should
> >>>> provide disable copy macro and use it in vtkClassMacro.
> >>>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>> On Thu, Sep 13, 2012 at 12:39 PM, Cory Quammen <cquammen at cs.unc.edu>
> wrote:
> >>>>>
> >>>>> +1 if you remove the constructors/destructor declarations.
> >>>>>
> >>>>> Cory
> >>>>>
> >>>>> On Thu, Sep 13, 2012 at 11:33 AM, Patchett, John M <
> patchett at lanl.gov>
> >>>>> wrote:
> >>>>> > Though I don't usually involve myself in VTK development, I think
> >>>>> > that obfuscated understandability is part of the reason that I've
> seen
> >>>>> > a large number of otherwise bright developers (students) become
> >>>>> > integration impotent when asked to put their ideas/code in
> >>>>> > VTK/ParaView...
> >>>>> > If a goal is to have contributors, this is a bad idea.
> >>>>> >
> >>>>> >
> >>>>> > --John.
> >>>>> >
> >>>>> >
> >>>>> > On 9/13/12 9:22 AM, "Marcus D. Hanwell" <
> marcus.hanwell at kitware.com>
> >>>>> > wrote:
> >>>>> >
> >>>>> >>On Thu, Sep 13, 2012 at 11:07 AM, Utkarsh Ayachit
> >>>>> >><utkarsh.ayachit at kitware.com> wrote:
> >>>>> >>>> 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.
> >>>>> >>>
> >>>>> >>> Note  that vtkTypeMacro() doesn't force you to add anything in
> the cxx
> >>>>> >>> file. You can pretty much not know what that macro does and
> you're
> >>>>> >>> okay. Not so with this macro. Also hiding constructor/destructor
> is
> >>>>> >>> really weird to me. Why would you? I don't think I am thrilled by
> >>>>> >>> having to implement function definitions without seeing their
> >>>>> >>> declarations in the header. None of the existing macros do that,
> not
> >>>>> >>> even in Qt, as far as I know. Readability of code is far more
> >>>>> >>> important that saving typing a few more lines, IMHO.
> >>>>> >>>
> >>>>> >>I can see your point with the contructor/desctructor. Even with
> them
> >>>>> >>removed I still think this macro would be very useful.
> >>>>> >>
> >>>>> >>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
> >>>>> >>
> >>>>> >
> >>>>> > _______________________________________________
> >>>>> > 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
> >>>>> >
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Cory Quammen
> >>>>> Research Associate
> >>>>> Department of Computer Science
> >>>>> The University of North Carolina at Chapel Hill
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> | Aashish Chaudhary
> >>>> | R&D Engineer
> >>>> | Kitware Inc.
> >>>> | www.kitware.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
> >>>
> > _______________________________________________
> > 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
>
>

-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120913/de4ce9cd/attachment.html>