[vtk-developers] Containers and... String

[Andy Cedilnik]

>A vtkCollection does in fact have ordering.  Anyway, I think that
>if VTK gets proper containers then those containers should at the
>very least support basic operators.  The operators could even be
>wrapped in Java and Python.


How can you wrap operators in java?
The problem is that (quote) "operators are ambiguous and are not intuitive".
I sort of agree with this, but I would not mind some operators to be there.

>Almost everywhere that a linked list is used, the 'vector' could be
>used instead with little or no loss of efficency.


Hmm, maybe, but I still think this should be let to the developer to decide.
If somebody needs a linked list, we should provide at least the interface for
it.

>You mean a hash table with exactly one value per hash?  Just let people
>set the hash function (either make it a virtual method or provide a
>SetHashMethod hook).


Actually no. Array implementation of associative array is not based on 
hashing, but on
position matching. Consider an array of pairs. First element in the pair is 
a key, second
element is a value. This way you can find find any element in linear time 
but it has virtually
no overhead.

>If they are templated, then they are only usable within the VTK classes
>i.e. they can't be wrapped.  I suppose this is fine, but I would still
>like to see vtkCollection turn into a proper 'vector' type so that doing
>things like going through the list of all actors in a renderer wasn't
>such a pain.

vtkCollection and such could use internally containers.

>Okay then, vtkString would basically just be a container for a char *
>to provide reference counting and other conveniences.  Also if you had
>several actors that were displaying the same text then you could just
>change the contents of the vtkString and all actors would update
>accordingly.
>
>Actually, one thing I would love to see is a massive clean-up of
>vtkDataObject and the subclassing of nearly all 'accessory' classes
>in VTK from vtkDataObject.  That way vtkTransform, vtkLookupTable,
>the new vtkString, vtkProperty, etc. could all be pipelined nicely.
>It would be possible e.g. to define a 'base' vtkProperty, and then
>send it through a vtkPropertyFilter which would allow adjustment of
>the color, opacity, ambient etc. so that it would be easy to make
>a set of actors with similar but differentiated properties.

Well, common containers would add severe cleanup to VTK.

                                 Andy