[vtk-developers] equivalent to vtkImageReader2 for polydata

[Michel Audette]

Hi again,

I think that I've purged them all. I'll monitor the dashboard for errors, to
make sure. I'll familiarize myself with Git Monday morning, and we can
revisit these changes afterwards.

It's been an interesting tutorial on tcl parsing errors for me today.

Have a good weekend.

Michel

On Fri, Jan 29, 2010 at 5:29 PM, Michel Audette
<michel.audette at kitware.com>wrote:

> Hi Berk,
>
> I made the commits prior to seeing this, but will revert right away to what
> was there before.
>
> Best wishes,
>
> Michel
>
>
> On Fri, Jan 29, 2010 at 4:49 PM, Berk Geveci <berk.geveci at kitware.com>wrote:
>
>> 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.
>> >
>> >
>>
>
>
>
> --
> Michel Audette, Ph.D.
> R & D Engineer,
> Kitware Inc.,
> Chapel Hill, N.C.
>
>


-- 
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100129/929cae90/attachment.html>