# Forward all methods of a structure
**URL:** https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783
**Category:** New to Julia
**Created:** [June 19, 2018, 1:42pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783 "2018-06-19T13:42:33Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@1115](https://discourse.julialang.org/u/1115)
#### Post date: [June 19, 2018, 1:42pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/1 "2018-06-19T13:42:33Z")
For example we have a struct
```julia
struct Daggered
block::Matrix
end
```
For any function `trait(m::Matrix, args...)`, can we define
```julia
trait(m::Daggered, args...) = trait(m.block, args...)
```
automatically to make Daggered look like a real matrix?
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [June 19, 2018, 1:56pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/2 "2018-06-19T13:56:51Z")
You code do this with some code generation. As a simple example
```julia
for op ∈ ops_i_want_to_use
@eval $op(m::Daggered, args...) = $op(m.block, args...)
end
```
though ideally you shouldn’t use splatting. In practice I often see people do this separately for unary, binary and trinary operators, but another (probably better) alternative would be to use [MacroTools.jl](https://github.com/MikeInnes/MacroTools.jl) which provides some really useful tools for deconstructing function syntax.
Note also that “`Daggered`” already exists, it’s called `Adjoint` and you can get it by just doing `A'` or `adjoint(A)` for some matrix `A`. (Be sure to import the package `Compat` first, as I’m showing syntax for 0.7 and I think `adjoint` was called something else in 0.6.)
One further comment, I’m not sure if your example was just demonstrative or intended as an actual use, but in general, if you want to create an array type, it should inherit from `AbstractArray`. For example
```julia
struct Daggered{T,N} <: AbstractArray{T,N}
block::Array{T,N}
end
```
this will then inherit all of the methods of `AbstractArray` (which is a lot). You only need to implement [a few simple functions](https://docs.julialang.org/en/latest/manual/interfaces/#man-interface-array-1) to make it work. One of the great virtues of Julia is that inheriting from abstract types in `Base` is a much more common practice than in any other language I have seen, and arrays are a really good example of how powerful this can be.
---
### Author:  [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [June 19, 2018, 2:04pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/3 "2018-06-19T14:04:26Z")
There is also the `@forward` macro from `Lazy.jl`:
```julia
help?> Lazy.@forward
@forward T.x functions...
Define methods for functions on type T, which call the relevant function on the field x.
Example
≡≡≡≡≡≡≡≡≡
struct Wrapper
x
end
@forward Wrapper.x Base.sqrt # now sqrt(Wrapper(4.0)) == 2.0
```
---
### Author:  [@1115](https://discourse.julialang.org/u/1115)
#### Post date: [June 19, 2018, 2:04pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/4 "2018-06-19T14:04:56Z")
Thanks for your reply,
code generation is a good idea, but not good enough.
For future extensions, we still have to define two set of functions for both Daggered and original version.
Adjoint has the same problem.
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [June 19, 2018, 2:12pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/5 "2018-06-19T14:12:09Z")
I’m not quite sure I’m understanding you correctly, but it sounds like you want to define a _new_ function for arrays, and then also extend that to a new type.
It might help if you could give a broader explanation of what you’re trying to do. It’s still sounding a bit like you just want some new `AbstractArray` methods, in which case what you should do is define `Daggered <: AbstractArray` and then simply define some methods which take an `AbstractArray` argument, i.e.
```julia
trait(A::AbstractArray, args...) = # some code
```
(perhaps see some [documentation](https://docs.julialang.org/en/latest/manual/types/#Abstract-Types-1) on abstract types).
Again, not sure if this is a real example, but `Daggered` of a matrix sounds quite a lot like an adjoint to me, so it might be worth looking through some of the array and linear algebra docs to see if what you’re doing is already implemented.
---
### Author:  [@1115](https://discourse.julialang.org/u/1115)
#### Post date: [June 19, 2018, 2:30pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/6 "2018-06-19T14:30:16Z")
Daggered may be a poor example, it was defined under the context of quantum circuit simulation in my case. Never mind …
I have read the source code of `Adjoint`, I think it is not elegant.
Let’s use the `Cached` object as an example,
In real programming, we often need something like `Cached` object that sharing the same interface with original object. It has difference only in some specific methods related to caching.
I need this kind of logic “struct A is same as B, only for functions in a countable set, it is treated special.”
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [June 19, 2018, 2:53pm UTC](https://discourse.julialang.org/t/forward-all-methods-of-a-structure/11783/7 "2018-06-19T14:53:07Z")
> [@1115](#):
>
> I need this kind of logic “struct A is same as B, only for functions in a countable set, it is treated special.”
That’s sounds quite a lot like inheritance to me. Ideally you’re objects would inherit from a common abstract type. If you are working with existing types that can’t do that, you can still generate functions as discussed above, but you may need to look through Julia introspection [tools](https://docs.julialang.org/en/latest/stdlib/InteractiveUtils/) for an automated way of finding them all.
For something like quantum circuits, I don’t think it’s a good idea to completely forsake all of the nice linear algebra functionality already existing in `Base`, so it’s good to at least be aware of it. Indeed, even if you have specialized operator types, it’s probably a good idea to also have methods which use `AbstractArray`s since in many cases the specialized operators will simply wrap those. At least in the finite dimensional case of quantum circuits, I can’t think of any reason why operators _shouldn’t_ be `AbstractArray`s, at least off the top of my head. It might be worth taking a look at [QuantumOptics](https://github.com/qojulia/QuantumOptics.jl) for some inspiration, it’s quite a nice package.