In general, we aim to alias actor method parameter and return type definitions that have not changed between versions onto to last changed version. We do this so that client Go code doesn't need to redundantly adapt structurally-identical types in order to continue interacting with unchanged methods.
The smoothing.FilterEstimate struct is included as a field in numerous method parameter or response objects. This type has logic (two methods) in addition to data. We hesitate to alias types with logic since it's much noisier in terms of commenting out code, and we want all the logic to be replicated directly in each version of actors. Its inclusion in method parameter/response objects precludes aliasing them: it's viral.
If we remove the two methods from FilterEstimate, and make them pure functions instead, then the FilterEstimate struct will be pure data which we can alias, and thence alias all the parameter/response objects too.
In general, we aim to alias actor method parameter and return type definitions that have not changed between versions onto to last changed version. We do this so that client Go code doesn't need to redundantly adapt structurally-identical types in order to continue interacting with unchanged methods.
The smoothing.FilterEstimate struct is included as a field in numerous method parameter or response objects. This type has logic (two methods) in addition to data. We hesitate to alias types with logic since it's much noisier in terms of commenting out code, and we want all the logic to be replicated directly in each version of actors. Its inclusion in method parameter/response objects precludes aliasing them: it's viral.
If we remove the two methods from FilterEstimate, and make them pure functions instead, then the FilterEstimate struct will be pure data which we can alias, and thence alias all the parameter/response objects too.