[vtk-developers] Modularization, Context2D and Tcl

David Cole david.cole at kitware.com
Wed Mar 28 21:34:28 EDT 2012


On Wed, Mar 28, 2012 at 7:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Wed, Mar 28, 2012 at 5:10 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Mon, Mar 26, 2012 at 1:31 PM, David Cole <david.cole at kitware.com> wrote:
>>> Thanks for the explanations.
>>>
>>> So... to piggy back on while we're making rather large changes anyway... :-)
>>>
>>> Would it make sense to rename the classes vtk2DHistogramItem,
>>> vtk3DSImporter and vtk3DWidget while we're at it? Just to avoid future
>>> problems as reported by David Gobbi's ruby wrapping fellow?
>>>
>>> Eventually, a namespace-enclosed set of VTK classes without the "vtk"
>>> prefix could be possible. But not if some of them start with numbers
>>> like those three.
>>>
>> If we were worried about legacy/keeping things simple for moves to VTK
>> 6 we could rename the classes, but provide an empty class deriving
>> from the renamed classes with the old names couldn't we? That class
>> could be enclosed in a legacy remove ifdef, and excluded from
>> wrapping. That might at least provide a path forward without too much
>> work for us, for the class I wrote with a bad name I am willing to
>> rename it.
>
> That sound sensible to me.  But remember that the problem that we're
> trying to solve, i.e. avoiding impossibilities like vtk::3DWidget, is
> still just a hypothetical problem.  We definitely want to avoid the
> proliferation of names like this, but at the same time, I don't think
> it's worth going to a lot of effort to remove the ones that already
> exist.
>
>  - David


It sounds sensible, but to be 100% compatible with people who may be
doing "IsA" tests using the classes in question, they should probably
be left intact in the class hierarchy where they are parents of other
classes, but then put the replacement classes in as parents of them,
move all the functionality to the newly named classes, but then
exclude the old ones from wrapping. Does that make sense?

Sort of like the templated data array classes were in the middle of
the hierarchy but without being exposed to the wrappers...

A break with instructions on how to rename would be better for classes
that are to be renamed, in my opinion. I always prefer a compiler
error to subtly changed runtime behavior.


Only 2 cents worth tonight,
David C.



More information about the vtk-developers mailing list