I like the idea of adding std:vector<> . As others said since we are augmenting the existing there shouldn’t be an API compatibility problem. If I remember correctly, the Python wrappers know how to deal with std::vector so the transition should be easy on that front.
Also, it streamlines and makes easier the serialization of an algorithms state.
That’s true but once the VTK classes are updated it would be relatively easy to update the Client/Server wrapping to accept those on top of what it accepts know . Of course this can happen independently in its own pace and only if/when needed.
Maybe we can wrap those in new macros like we do in vtkSet/Get ?
Indeed this is an issue. I suggest that the Getters return a copy in this case so that the method can remain const in C++ and avoid undesired effects. This allows also to keep the internal member variables intact. i.e. we can introduce the new API leaving internally the member as a plain array.