[vtk-developers] Containers and... String

[Andy Cedilnik]

>Instead of making a vtkVector class, just expand the vtkCollection
>class (which is already used all over the place).  I would love,
>for example, to be able to use the collection[] and *collection++.

Hmm, operators are against the religion the way I see it.
Collection does not have any ordering information. List on the other hand 
has a very
strict ordering.

> >       - vtkLinkedList, which is a linked list implementation
>
>Unnecessary as far as I can see, it's probably best not to provide
>a linked list.


There is a linked list of observers inside the vtkObject. This one could be 
replaced with
more efficient vtkLinkedList

> > AssociativeArray contains:
> >       - vtkHashTable, which is a hash table implementation
>
>An efficient hash table would be a very useful thing.
>
> >       - vtkTree, which is a (red-black) tree implementation
>
>Again, possibly unnecessary.

I don't know about the tree, maybe someday somebody will need it. We can 
leave space
for it.

> >       - vtkArrayTable, which is an array implementation
>I'm not quite sure what this is.

Well, two arrays. I guess linear one-to-one mapping from one type to another.
Good for simple hashing, where you do not want the overhead of hash table.
Hmm, maybe unnecessary.


> > vtkContainer class is not subclass of vtkObject, so that we
> > can use containers inside vtkObject class for things such
> > as Observers.
>
>I would much prefer that the containers are subclassed from
>vtkObject, so that they can be reference counted etc.  Also,
>wrapping classes that are not derived from vtkObject is a pain.
>Finally, I would like it if all the 'items' in the containers
>are vtkObjects.

We can add reference counting to vtkContainer the same way as vtkCommand
does it. The problem of container being subclass of vtkObject is that then we
cannot use containers directly in vtkObject.
I would also make containers templated so that you can put vtkObject in it
but you can also put anything you want.

> > Comments?
> >
> > On the side note, I also think we need a vtkSring class.
>
>Again, I would like to see this derived from vtkObject.  It should
>specifically be a 'vtk string', not just a re-implementation of
>the stl string (re-implementing stl strings would be a rather
>pointless exercise IMHO).


Well, considering the fact that STL is a no-no for VTK, we can implement a 
simple
string class. This one could be a subclass of vtkObject, but as said, we 
cannot use
it in vtkObject.

                         Andy