[vtkusers] Design Gripes

[Bill Lorensen]

bool is still not supported on all the vtk platforms... Seems unlikely, but it is true...

At 05:23 PM 3/28/02 -0500, Murad Nayal wrote:

>Dear Dr. Martin
>
>Thanks for the feedback. sorry I didn't notice previous discussions.
>glad to know the user guide is up to date on vtk 4.0. Just ordered a
>copy.
>
>also for reasons of code clarity, I would advocate vtk use bool instead
>of int for boolean variables. I wouldn't think there is a C++ compiler
>that won't understand bool right now. I suppose backward compatibility
>issues might also be a concern here.
>
>another aspect that would be on my wish list in a perfect world would be
>adoption of the STL in vtk.
>
>regards
>
>Ken Martin wrote:
>> 
>> I'll address only one issue here since the others have been beat on in
>> the past. The void (*)(void *) stuff is all old style code left in for
>> backwards compatibility. I would gladly yank it out but... then a
>> bunch of people would (with good reason) scream that their code no
>> longer works. The new style is to use the command observer design
>> pattern which is implemented in vtkCommand.h. It supports callbacks
>> with state etc. The examples in VTK/Exmaples/Tutorial/Step2 all show
>> callbacks using the new observer style. The VTK 4.0 user guide also
>> only discusses the new style of observer not the old style void (*)
>> ...  Unfortunately leaving the old style code in for backwards
>> compatibility can be confusing and misleading to new users. In an
>> ideal world someone should modify the comments above the old style
>> code to indicate that it is no longer the preferred way to do this.
>> 
>> Thanks
>> Ken
>> 
>> > Vector3D class. Also, it would be really nice if call back functions
>> > were function objects that can maintain state. programming
>> > with function
>> > pointers like void (*)(void*) and associated argument
>> > delete functions
>> > seems clunky at best. I know there are constraints related to the
>> > underlying graphics libraries. but this still could be
>> > implemented with
>> > no more than an additional indirect function call overhead.
>> > would that
>> > be so bad for performance? etc..
>> >
>> > I found the book helpful in getting to know the mindset of the
>> > designers. any plans to provide an updated edition for
>> > vtk4? Are there
>> > any other design documents that cover vtk4?
>> >
>> > best,
>> >
>> >
>> > --
>> > Murad Nayal M.D. Ph.D.
>> > Department of Biochemistry and Molecular Biophysics
>> > College of Physicians and Surgeons of Columbia University
>> > 630 West 168th Street. New York, NY 10032
>> > Tel: 212-305-6884     Fax: 212-305-6926
>> > _______________________________________________
>> > This is the private VTK discussion list.
>> > Please keep messages on-topic. Check the FAQ at:
>> > <http://public.kitware.com/cgi-bin/vtkfaq>
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtkusers
>
>-- 
>Murad Nayal M.D. Ph.D.
>Department of Biochemistry and Molecular Biophysics
>College of Physicians and Surgeons of Columbia University
>630 West 168th Street. New York, NY 10032
>Tel: 212-305-6884       Fax: 212-305-6926
>_______________________________________________
>This is the private VTK discussion list. 
>Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/vtkusers