[vtk-developers] equivalent to vtkImageReader2 for polydata

[Berk Geveci]

>> 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.
>
> This recreates the problem Michel asked about earlier.  Does a poly data
> reader derive from vtkPolyDataAlgorithm or vtkAbstractDataReader?
> Without multiple inheritance we need to choose.

No, it does not. I was saying:

vtkAlgorithm <- vtkAbstractDataReader <- vtkDataReader <- vtkPolyDataReader

vtkPolyDataAlgorithm implements a few trivial things that could easily be
duplicated by other readers so it doesn't have to be there at all. Note that
vtkPolyDataReader is not a subclass of vtkPolyDataAlgorithm anyway.

I want to clarify that I am not suggesting doing this. I am suggesting
investigating
if doing this is a good idea. I am not sure what common API all
readers will have
so one would have to investigate that. You'd think SetFileName would be common
but I know several readers that require multiple file names or some sort of
pattern to match multiple files.

I took a quick look at vtkImageReader2 and it is quite a mess. It
essentially has
a union of of the APIs of all subclasses to set the filename. How does one know
which method to use? It has methods to set things like DataSpacing. What if the
file already contains that meta-data? Does it override? Scary stuff.

-berk
On Fri, Jan 29, 2010 at 2:28 PM, Brad King <brad.king at kitware.com> wrote:
> Berk Geveci wrote:
>> 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.
>
> This recreates the problem Michel asked about earlier.  Does a poly data
> reader derive from vtkPolyDataAlgorithm or vtkAbstractDataReader?
> Without multiple inheritance we need to choose.
>
> -Brad
>