Hi Berk, <br><br>I made the commits prior to seeing this, but will revert right away to what was there before. <br><br>Best wishes, <br><br>Michel<br><br><div class="gmail_quote">On Fri, Jan 29, 2010 at 4:49 PM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Can you push your code to Git first so that people can review it<br>
first? You are changing<br>
a core portion of VTK's IO use by thousands of people. It should not<br>
be done without<br>
multiple pairs of eyes checking it.<br>
<br>
-berk<br>
<br>
On Fri, Jan 29, 2010 at 2:44 PM, Michel Audette<br>
<div class="im"><<a href="mailto:michel.audette@kitware.com">michel.audette@kitware.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> Hi Berk,<br>
><br>
> I'm okay with your naming suggestion. I'll use vtkAbstractPolyDataReader .<br>
> I'll refrain from using 2 in the Collection and Factory. Does the word<br>
> Abstract belong in those two? My feeling is not. Too bad about not being<br>
> able to rename ImageReader2-related classes to Abstract-something.<br>
><br>
> In keeping with Brad's response, I'll maintain the derivation from<br>
> vtkPolyDataAlgorithm. Moreover, I want to proceed in as similar to<br>
> ImageReader2 as possible, without reinventing the hierarchy.<br>
><br>
> I'd like to commit my code this afternoon. I have a few test files as well<br>
> that use stl and vtk data in VTKData.<br>
><br>
> Cheers,<br>
><br>
> Michel<br>
><br>
><br>
> On Fri, Jan 29, 2010 at 2:17 PM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>><br>
> wrote:<br>
>><br>
>> > In response to Berk, my justification for calling this reader<br>
>> > vtkPolyDataReader2 was based on a notion of backward compatibility,<br>
>> > given that this reader is exactly analogous to vtkImageReader2.<br>
>><br>
>> Backwards compatibility is not the right term. You mean consistency.<br>
>> Being consistent with a bad precedent is not necessarily the right thing.<br>
>><br>
>> > I'm open to calling it vtkFlexiblePolyDataReader or something in that<br>
>> > spirit, but some thought should be given to renaming vtkImageReader2<br>
>><br>
>> vtkFlexiblePolyDataReader is slightly better but still quite bad. We have<br>
>> been using "Abstract" or "Base" to represent abstract superclasses. So<br>
>> it needs to be vtkAbstractPolyDataReader or vtkPolyDataReaderBase.<br>
>><br>
>> Renaming vtkImageReader2 has the problem of breaking backwards<br>
>> compatibility. I would love to see it renamed but I am not sure if it is<br>
>> worth breaking all of the external code that uses it.<br>
>><br>
>> > in a comparable manner, otherwise the naming convention becomes even<br>
>> > more confusing. Moreover, it's been suggested that I also implement<br>
>> > such a reader for vtkUnstructuredGrid, so one option would be to call<br>
>> > all of these vtkXXXReader2 for now, and vtkFlexibleReader at the next<br>
>> > release.<br>
>><br>
>> I did not suggest implementing a base for unstructured grid readers. I<br>
>> suggested implementing a base of all readers, something like<br>
>> vtkAbstractDataReader.<br>
>> ALL VTK readers would be a descendant of this class.<br>
>><br>
>> -berk<br>
><br>
><br>
><br>
> --<br>
> Michel Audette, Ph.D.<br>
> R & D Engineer,<br>
> Kitware Inc.,<br>
> Chapel Hill, N.C.<br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Michel Audette, Ph.D. <br>R & D Engineer, <br>Kitware Inc.,<br>Chapel Hill, N.C. <br><br>