I’ve filed an issue outlining problems with the current set of
vtkCollection APIs that are exposed. The issue states the problem and this thread is meant to discuss possible solutions (conclusions will go back to the issue).
Just to lay some groundwork for what barriers definitely exist, there are some design solutions that are banned due to C++ language design.
Mainly, C++ lacks
const-specific subclass casting (e.g., given
class T: public U,
static_cast<U*>(T*) is always just as valid as
static_cast<U const*>(T const*) even though
static_cast<U const*>(T*) is the only valid cast given the API), so there’s no inheritance mechanism we can do to factor out common APIs too easily. Mixins can probably help, but the wrappers will need support for that I imagine.
Insertion into the collection can ensure that the object to be inserted is actually of the collection’s expected type.
- When inserting, the code doing the inserting can get notified (probably via a return flag) if it worked
- Fast retrieval
- Slower insertion
- Needs a new
virtualAPI to understand what the actual type’s required type is
GetNextX() can use
vtkX::SafeDownCast to ensure that any invalid items in the collection are returned as a
- No new API required
- Fast insertion
- Slower retrieval
- Ends iteration early due to the
nullptralso being a sentinel for the end of the collection
- Method name is now unclear (should
GetNextActor()iterate until it finds an actor?)
- Insertions can “poison the well” from “anywhere” since there’s no checking at that time
vtkCollection<T> could be implemented to indicate that it is a collection over type
T. This would likely be handled similarly to the
vtkDataArray templates for the wrappers.
Using this, we could have the ability to cast from
const vtkCollection<T>* to
const vtkCollection<U>* since there is no direct inheritance that C++ would force on us. How to expose this in wrapper APIs is a separate question since there’s no wrapper overloading base on
Of course, the type could also try to resolve the
const conflation difference between
vtkCollection<const T> and
const vtkCollection<T> instead of (probably) only acting as if
const vtkCollection<const T> exist.
- Greenfield development, so no breaking APIs required (just a lot of deprecations)
- Wrapping complexities
- Need a new name since
vtkCollectionis already taken
- Needs some
const-correctness to get utility of being able to access