Inheritance vs. mulitple dispatch in julia is maybe one of the hard things to grasp. I am still struggling with it and therefore the question. Does julia have a concept of carrying over data members to derived classes? I have read about multiple dispatch being what replaces the need for multiple inheritance and I can see how this may be true for methods, but what about data? To demonstrate, here is an example using @tholy ’ s class AxisArray:
julia> V = AxisArray(rand(3); row='a':'c')
1-dimensional AxisArray{Float64,1,...} with axes:
:row, 'a':1:'c'
And data, a 3-element Vector{Float64}:
0.3122957215062174
0.6611468595604877
0.6639367902035573
julia> V = AxisArray(rand(3); row='a':'c')
1-dimensional AxisArray{Float64,1,...} with axes:
:row, 'a':1:'c'
julia> V2 = V .+ 0
And data, a 3-element Vector{Float64}:
0.3122957215062174
0.6611468595604877
0.6639367902035573
As it is seen, the addition of 0 already removes the nice axis properties from the array. Even more so, also views of the array burry its nice properties:
julia> V3 = reshape(V,(1,3))
1×3 reshape(::AxisArray{Float64, 1, Vector{Float64}, Tuple{Axis{:row, StepRange{Char, Int64}}}}, 1, 3) with eltype Float64:
0.312296 0.661147 0.663937
julia> V3.axes
ERROR: type ReshapedArray has no field axes
One may now argue that it is in the responsibility of the package author to write multiple-dispatch methods such that for example such views are also supported. But this is a task which would not be necessary in ordinary inheritance schemes where the data members are essentially just copied and new data members can appended.
The problem: Am I missing an important julia feature or way of usage in my toolbox, or is this a current limitation of julia or an unavoidable limitation?
In my mind the usefulness of AxisArrays (and all programming which adds data to existing structures) is extremely limited if the user always have to keep track of the axis data. In this case a separate axis class is more useful (which may of course exist already), but it just seems wrong, since a set of axes should belong to the array and should be propagated along with what is done to the array.
I guess the broadcasting mechanism can somehow be carried over to AxisArrays but what about the views? How about introducing a julia keyword persist, which tells a data member to conceptually automatically reside (or be accessible from) structure of the encapsulating structure?
This way it would be fairly easy to deal with the views, as the axis would “blubble up” though a series of such encapsulations and still be visible. But then this needs some change to the type structure, as the resulting view type needs to still ideally be recognized a subtype of AxisArrays and not just AbstractArray, I guess.