[vtk-developers] equivalent to vtkImageReader2 for polydata

Berk Geveci berk.geveci at kitware.com
Fri Jan 29 16:49:52 EST 2010


Can you push your code to Git first so that people can review it
first? You are changing
a core portion of VTK's IO use by thousands of people. It should not
be done without
multiple pairs of eyes checking it.

-berk

On Fri, Jan 29, 2010 at 2:44 PM, Michel Audette
<michel.audette at kitware.com> wrote:
> Hi Berk,
>
> I'm okay with your naming suggestion. I'll use vtkAbstractPolyDataReader .
> I'll refrain from using 2 in the Collection and Factory. Does the word
> Abstract belong in those two? My feeling is not. Too bad about not being
> able to rename ImageReader2-related classes to Abstract-something.
>
> In keeping with Brad's response, I'll maintain the derivation from
> vtkPolyDataAlgorithm. Moreover, I want to proceed in as similar to
> ImageReader2 as possible, without reinventing the hierarchy.
>
> I'd like to commit my code this afternoon. I have a few test files as well
> that use stl and vtk data in VTKData.
>
> Cheers,
>
> Michel
>
>
> On Fri, Jan 29, 2010 at 2:17 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>>
>> > In response to Berk, my justification for calling this reader
>> > vtkPolyDataReader2 was based on a notion of backward compatibility,
>> > given that this reader is exactly analogous to vtkImageReader2.
>>
>> Backwards compatibility is not the right term. You mean consistency.
>> Being consistent with a bad precedent is not necessarily the right thing.
>>
>> > I'm open to calling it vtkFlexiblePolyDataReader or something in that
>> > spirit, but some thought should be given to renaming vtkImageReader2
>>
>> vtkFlexiblePolyDataReader is slightly better but still quite bad. We have
>> been using "Abstract" or "Base" to represent abstract superclasses. So
>> it needs to be vtkAbstractPolyDataReader or vtkPolyDataReaderBase.
>>
>> Renaming vtkImageReader2 has the problem of breaking backwards
>> compatibility. I would love to see it renamed but I am not sure if it is
>> worth breaking all of the external code that uses it.
>>
>> > in a comparable manner, otherwise the naming convention becomes even
>> > more confusing. Moreover, it's been suggested that I also implement
>> > such a reader for vtkUnstructuredGrid, so one option would be to call
>> > all of these vtkXXXReader2 for now, and vtkFlexibleReader at the next
>> > release.
>>
>> I did not suggest implementing a base for unstructured grid readers. I
>> suggested implementing a base of all readers, something like
>> vtkAbstractDataReader.
>> ALL VTK readers would be a descendant of this class.
>>
>> -berk
>
>
>
> --
> Michel Audette, Ph.D.
> R & D Engineer,
> Kitware Inc.,
> Chapel Hill, N.C.
>
>



More information about the vtk-developers mailing list