# Solutions for vtkCollection API issues
**URL:** https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787
**Category:** Development
**Created:** [October 8, 2021, 2:16pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787 "2021-10-08T14:16:42Z")
**Posts on this page:** 7
**Page:** 2
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [November 15, 2021, 9:12pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/21 "2021-11-15T21:12:23Z")
But the instance is then mutable!
I think the fundamental problem with any wrapper code is that no other languages, AFAIK, support passing const reference parameters.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [November 15, 2021, 9:18pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/22 "2021-11-15T21:18:49Z")
If you got a `vtkHomogeneousTransform*`, sure. If you got `const vtkHomogeneousTransform*`, then you also need `const_cast` (with its various caveats and footnotes about its use).
The problem isn’t mutability. It’s mutability _as the wrong type_. A `vtkPerspectiveTransform` has limits on what it can represent; using it as the more general `vtkHomogeneousTransform` is just asking to violate those invariants.
Consider this:
```auto
class Ellipse {
double minor;
double major;
public:
Ellipse(double major, double minor) : major(major), minor(minor) {}
};
class Circle : public Ellipse {
public:
Circle(double r) : Ellipse(r, r) {}
void set_radius(double r) { major = minor = r; }
};
```
If `Ellipse::set_minor()` existed, `Circle::set_minor()` could be called. This…does not work well unless `Ellipse` knows to also update `major` at the same time. However, if I have `Ellipse* e`, `dynamic_cast(e)->set_radius(0.1)` is just fine (modulo `nullptr` checks).
---
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [November 15, 2021, 9:36pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/23 "2021-11-15T21:36:21Z")
We seem to be talking at cross purposes.
I thought the issue was having add/insert methods defined too low in the class hierarchy which allowed base types into the collection. But surely this can be handled via templating. So the only other issue is when you want to only permit iteration in some parts of the code. If the collection can be cast dynamically it becomes mutable.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [November 15, 2021, 10:01pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/24 "2021-11-15T22:01:20Z")
> [@toddy](#):
>
> If the collection can be cast dynamically it becomes mutable.
Yes, but to an API that properly constrains it (or you get `nullptr` back on the cast to an improper type). If you get a `const vtkXCollection*`, no amount of casting (other than the “I’m asking for trouble `const_cast`” case) will get you a mutable collection.
---
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [November 15, 2021, 10:15pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/25 "2021-11-15T22:15:52Z")
> [@ben.boeckel](#):
>
> If you get a `const vtkXCollection*`, no amount of casting (other than the “I’m asking for trouble `const_cast`” case) will get you a mutable collection.
How do you propose this should be catered for in wrapper code?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [November 15, 2021, 11:24pm UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/26 "2021-11-15T23:24:10Z")
Indeed, wrappers do have decisions to make. With Python, shimming in `vtkFoo_const` classes probably isn’t _too_ hard, just probably very confusing if/when backtraces end up happening. You also have this problem:
```python
class vtkFoo_const(vtkBase):
pass # const methods
class vtkFoo_nonconst(vtkFoo_const):
pass # add in non-const methods
class vtkBar_const(vtkFoo_const):
pass
# How to do this? Mixins? But then how to make a "real" vtkFoo?
class vtkBar_nonconst(vtkBar_const, vtkFoo_nonconst):
pass
```
Alas, wrapping will always have some mismatches that occur. Python could probably get away with something like a metaclass like `vtkConst(vtkFoo)` that wraps member access as `vtkConst()` objects and throws on any mutable method call (`const`-overloads would need some assistance here).
I don’t know Java well enough to know how it’d work there.
Either way, I think if the C++ API isn’t sound, the wrappers have zero chance of getting it right. If the wrappers have something they can’t handle, then it’s an API not accessible to them. I don’t think they should have absolute veto over something, but they certainly can influence it, but also not to the point of making the C++ API a ball of barbed wire.
---
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [November 16, 2021, 12:15am UTC](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/27 "2021-11-16T00:15:55Z")
> [@ben.boeckel](#):
>
> ```auto
> # How to do this? Mixins? But then how to make a "real" vtkFoo?
> class vtkBar_nonconst(vtkBar_const, vtkFoo_nonconst):
> pass
>
> ```
You do this with _interfaces_ in Java.
So in the class diagram below the **vtkAbstractContainer** class would become **vtkContainerInterface** implemented by both **vtkContainer** (_non-const_) and **vtkContainerDecorator** (_const_). Then rinse and repeat inheriting from the _const_ and _non-const_ classes and introducing new interfaces.
> [@Solutions for vtkCollection API issues](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787/19):
>
> A flaw in this is that there’s nothing to prevent vtkHomogeneousTransform from being dynamically cast to vtkPerspectiveTransform in the downstream code. So here’s an alternative using composition and the decorator pattern where the “internal” methods are virtual. When an immutable const vtkAbstractContainer& parameter is declared the wrapper code can generate a vtkContainerDecorator instead.
[Previous page](https://discourse.vtk.org/t/solutions-for-vtkcollection-api-issues/6787.md?page=1)