I appreciate the effort, but I don’t think (and many with me as evidenced by e.g. this topic) this is a satisfactory solution. It is of linear complexity in the API size, as opposed to constant complexity for traditional structure based inheritance, and it does not solve the fragility issue (augmented or modified APIs are not automatically picked up).
Would the issue not be solved if for every composite type the compiler would generate an associated anonymous abstract parent type and that inheritance from a composite would imply inclusion of its field and inheritance from the implied anonymous abstract type?
So, if I write:
immutable Base
x::Int
end
this would be lowered to
abstract AbstractBase
immutable Base <: AbstractBase
x::Int
end
and when I write
immutable Derived <: Base
y::Int
end
this is taken to mean
abstract AbstractDerived <: AbstractBase
immutable Derived <: AbstractDerived
@includefieldsfrom Base
y::Int
end
Then if a function
f(obj::Base) = @show obj.x
is lowered to
f(obj::AbstractBase) = @show obj.x
it will also match objects of type Derived.
I feel these issues stem from the fact that types can either signify data layout or dispatch behaviour and that most programming languages including Julia mix up the two.