That’s the trickiest thing; actually I’d say that it’s generally impossible, but not for lack of tools, but because by definition there is no closed list of “methods for X” or “methods for Foo”.
methodswith(X) may help you get a list of methods that you would like to extend at some point, and with a bit of metaprogramming you might extend all of them at once so that they work for Foo instead of X.(*) But then, maybe you do using Bar, which defines new methods for X, and your “extension” becomes incomplete.
And the “bad news” is that there is no way at all to anticipate what new methods may come from other packages. (Of course “bad news” only for the purpose of what we are discussing; in general that’s what makes composability easier.)
(*) Even for a limited list of “methods for X”, extending them so that they take Foo instead of X is not always straightforward. For instance, how would you extend *(::X, ::X)? Shall it be *(::Foo, ::Foo), or also other combinations with X and Foo?
No, there is no structural inheritance. That’s what this whole thread is about. Having structural inheritance makes inlining much harder, forces the compiler to chase endless pointer chains by default and makes the size of an given struct possibly indeterminate (possibly preventing SIMD).
The point is that choosing composition over structural inheritance makes that choice explicit and makes the job of the compiler easier. You can’t subtype concrete types in julia and abstract types don’t have fields. Together with functions and their arguments not being coupled to any particular struct definition, you’re free to define methods extending a given implementation with your type without having to touch the existing code at all.
The functions (i.e. operations) define your API - not necessarily your struct layout, i.e. how you store what you need.
@heritable struct MyParentType
my_field::SomeOtherType
end
Which writes the code:
abstract type MyParentType end
struct ConcreteMyParentType
my_field::SomeOtherType
end
and then write
@inherit struct MyChildType <: MyParentType
extra_field::SomeType
end
which writes the code:
struct MyChildType <: MyParentType
parent_type::MyParentType
extra_field::SomeType
end
MyChildType(x1::SomeOtherType, x2::SomeType) = new(MyParentType(x1), x2)
function getproperty(m::MyChildType, s::Symbol)
if s .∈ fieldnames(m)
return getfield(m,s)
else
return getfield(m.parent_type,s)
end
All methods defined on MyParentType are actually defined on an abstract type because the the macro defines the struct with the “concrete” prefix. Methods defined on MyParentType will correctly work on a subtype of MyParentType because the getfield function also looks for the fields in the parent type – unless the child type is given a field with the same name as a parent field.
I’m not sure if it would be possible to conveniently extend this approach to multiple inheritance, because you would have to write a macro extending methods defined on the second parent type to MyChildType, which is not a proper subtype of the other parent.
Surprised that the following JuliaLang/julia Issue hasn’t been discussed here yet: https://github.com/JuliaLang/julia/issues/4935. The proposed feature exactly addresses the problem debated here.
Just for reference for people reading this thread I figure I’d highlight [ANN] CompositeStructs.jl which is maybe the least restrictive of these packages (ConcreteAbstractions.jl, Mixers.jl, Classes.jl, …) that try to mimick inheritance. Anyway, like the author of ConcreteAbstractions, I don’t feel strongly that this is a “great” solution that should be used alot, but maybe useful in certain situations.
This thread is gold. Got to this point and now I understand a lot more about OOP and Julia type dispatch style paradigms (which I like better, now I know why). FWIW I’m not a CS person.
your idea seems to solve my requirements exactly. I have to define a complex state that sometimes contains substates of partially the same entry types as the main state itself.
I wonder how to do this inheritance using Base.@kwdef. If I modify
res = :(mutable struct $name end)
into
res = :(Base.@kwdef mutable struct $name end)
I get the error: syntax: invalid type signature
Seems it’s a matter of macro evaluation…