Closed jonniedie closed 2 years ago
I think that these fields were added as a convenience back in the day when one could not overload getproperty. I think it would be safe to add them to getproperty and remove the fields? @mfalt can you see any reason to keep them around, other than the nice way of accessing the sizes?
I think that these fields were added as a convenience back in the day when one could not overload getproperty. I think it would be safe to add them to
getproperty
and remove the fields?
I absolutely agree, I have been thinking this a couple of times as well
This should be solved for statespace types now since we removed the internal fields that were no longer required. Might still be a problem for transfer functions though.
Some useful functions that need to recurse through arbitrarily nested
struct
s and rebuild them with different values--like@set
and@set!
from Setfield.jl orreplace_particles
(along with its derived functionsmean_object
andnominal
) from MonteCarloMeasurements.jl--require constructors that match the positions of the type's fields. SinceTransferFunction
andStateSpace
have fields for their number of inputs/outputs[/states], but no constructors that take them in, it creates problems for these types of functions. For example, these don't currently work:but adding
makes it so they work:
This and the similar method for
TransferFunction
, are all that's needed for these types of functions to work. I can make a pull request with these, if it would be useful.