Changing struct fields to a different sub-type during run time

[Benny]

@stevenhughes

I know using abstract types here causes major performance problems so I have avoided that.

@stevenhughes

mutable struct Spacecraft
    state::OrbitState
    time::SpacecraftTime
end

These fields are still declared with abstract types, and that’s what the compiler sees given the concrete Spacecraft. For example, the compiler can only see getfield(s, :state)::OrbitState in getproperty(s::Spacecraft, :state), so it can infer the return value as ::AbstractState at best, not the likely concrete state::T. Note that @code_warntype sc.state would give you a more pessimistic report that doesn’t consider how the literal :state is specially propagated for getproperty to narrow down the branch. At the moment, it’s not clear how this layer of indirection has any advantage over:

mutable struct SpacecraftDirect
    state::AbstractState
    time::AbstractTime
end

@stevenhughes

I would overload get/set property so users only work with the concrete time and state types

getproperty and setproperty returns instances, which will always have concrete types at runtime i.e. neither typeof(sc.state) nor typeof(sc_direct.state) would ever be abstract. The abstract declared types OrbitState or AbstractState are only exposed to the users if they directly reference them or use reflection functions like fieldtypes(Spacecraft) or fieldtype(SpacecraftDirect, :state).

Without any indication of how these instances are passed into and used in methods, it’s impossible to tell where this compromises performance and how you may limit that. I’d also suggest you vastly change the tags of this question if it will only concern the base type system; there would be no reason to specially categorize this topic for aerospace simulations or imply readers need any such experience to interact.