# Merging composite types - multiple inheritance of fields/mixins

**URL:** <https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458>\
**Category:** Internals & Design\
**Tags:** inheritance, structtypes\
**Created:** [April 20, 2018, 3:01pm UTC](https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458 "2018-04-20T15:01:08Z")\
**Posts on this page:** 4\
**Page:** 1

<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 20, 2018, 3:01pm UTC](https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458/1 "2018-04-20T15:01:09Z")

</div>

This has been talked about a lot before - the lack of mixin functionality in julia.

But I’ve been thinking about mixins a lot – for merging existing composite types to balance modularity with simplicity when using lots of micro-modules to assemble complex models.

Heres a toy example. My real examples have a lot more parameters – that’s the reason for avoiding just writing them out again, as would probably be the best idea here:

```julia
struct FirstStruct{T}
    par1::T  
    par2::Float64
end

struct SecondStruct{T}
    par3::T  
    par4::Int
end

@mergecomposite CompositeStruct FirstStruct SecondStruct

```

Which generates:

```julia
struct CompositeStruct{T1, t2}
    par1::T1  
    par2::Float64
    par3::T2  
    par4::Int
end

```

First I’m wondering about this as a design pattern, and how people are doing mixin patterns in 2018, if they are at all? Any reasons this is not a good idea?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 20, 2018, 3:52pm UTC](https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458/2 "2018-04-20T15:52:17Z")

</div>

AFAIK the consensus is that in Julia you should prefer _containment_. Search for [“containment inheritance”](https://duckduckgo.com/?q=containment+inheritance) for a lot of opinions about the topic in general. A macro could construct

```julia
struct CompositeStruct{T1, T2}
    a::T1
    b::T2 
end

```

but IMO it is hardly worth the loss of transparency. The key part is implementing functionality of elements, see eg [`Lazy.@forward`](https://github.com/MikeInnes/Lazy.jl) to automate this.

---

<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 20, 2018, 10:47pm UTC](https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458/3 "2018-04-20T22:47:01Z")

</div>

Mostly I’m using totally parametric types and no methods as these are model parameters - there is only ever one set. So Lazy.@forward isn’t necessary. (I’m writing all the sub-modules so I get to make that decision). Any inheritance or methods would be using holy traits, like “has field param1”

This combination seems to remove a lot of the arguments for composition over inheritance, and the arguments against containment become more important: data structures can get too complex and nested.

But I can see the case fo keeping the modularity clear and explicit in the data structures. Guess I’ll have to try both and see how it feels.

---

<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 21, 2018, 11:23pm UTC](https://discourse.julialang.org/t/merging-composite-types-multiple-inheritance-of-fields-mixins/10458/4 "2018-04-21T23:23:28Z")

</div>

For anyone researching this issue later on: after going with containment for a day I’m beginning to think that even thinking about doing things the way I originally suggested is probably a code smell. I solved so many issues just using containment. Flattening nested fields isn’t that hard either if you really need it for something

A simple @def macro for inserting repeared non-parametrically typed fields is a useful DRY mixin pattern and probably as far as mixins should ever go.