# Multiple inheritance carry-over members

**URL:** <https://discourse.julialang.org/t/multiple-inheritance-carry-over-members/58355>\
**Category:** General Usage\
**Tags:** inheritance, arrays\
**Created:** [April 1, 2021, 11:00am UTC](https://discourse.julialang.org/t/multiple-inheritance-carry-over-members/58355 "2021-04-01T11:00:16Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [April 2, 2021, 11:02pm UTC](https://discourse.julialang.org/t/multiple-inheritance-carry-over-members/58355/8 "2021-04-02T23:02:47Z")

</div>

> and it failed to do its job

I think you misunderstand the scope of what you want here. It’s job doesn’t really extend into the constructors of ecosystem packages that I don’t know about, I can’t see how this would “just work” in any language. How do we influence the `PaddedView` constructor? and what should happen if you try to wrap it with a NamedDims.jl wrapper? which should “win”?

But it _is_ possible to solve this with very little boilerplate code, and as usual in Julia, it would need some (a lot of) coordination and a shared interface (as you suggest with AbstractArray, but probably actually with traits and shared methods in an interface package like ArrayInterface.jl).

The simple case would be that `PaddedView` has a method that dispatches on `DimArray` and rewraps. But to generalise to AxisArrays,jl and NamdDims.jl and any other wrapper type, we could have a method in ArrayInterface.jl - `rewrap(f, A)`. `PaddedView` and other array packages could call `rewrap` in their constructor. The default `rewrap` would just call `f` and return it. But DimensionalData.jl could add a method to unwrap the internal array, run the constructor `f`, and wrap it with a `DimArray` again.

Someone would have to write this, and packages would have to implement it. Probably a lot wouldn’t, but as ArrayInterface.jl is more widely accepted, things like this may start to work?

Broadcast can handle this a little better - it’s possible to make DD always “win” as the outer wrapper. I’m not sure how well it goes currently with other packages. Probably `NamedDims.jl` wrappers would beat it as @oxinabox understands broadcast better than I do.

Composition is what we are doing by wrapping objects that already have behaviors, instead of inheriting behaviours from a supertype, as we are with `AbstractArray`. But I meant that comment in relation you question about field inheritance, which is actually unrelated to this problem. Regular inheritance doesn’t apply in this context because `PaddedView` does not inherit from or know about `AbstractDimArray`, it inherits from `AbstractArray` - so composition is all we can do.

This is a problem of agreeing on ecosystem wide shared interfaces, and working out what they need to do and agreeing to implement them. Maybe some of them will make it into Base one day. That’s what ArrayInterface.jl is for, but these things are a long way off.

Personally, I just use `DimensionalData.rebuild` for this kind of thing:

```julia
rebuild(some_dimarray, PaddedView(parent(some_dimarray), args...))

```

Which of course will break the index if `PaddedView` changes the array size, another complication to this issue. Doing that generically would need `rewrap(f, A, I...)`

See: [interface for rewrapping Array wrappers · Issue #136 · JuliaArrays/ArrayInterface.jl · GitHub](https://github.com/JuliaArrays/ArrayInterface.jl/issues/136)

---

_[View the full topic](https://discourse.julialang.org/t/multiple-inheritance-carry-over-members/58355)._