The original frost::Coordinator provided basic functionality, but the new fire::Coordinator does much more in terms of handling timeouts etc, even without the byzantine handling.
In a reasonable OO language, it would be trivial to pull the common code into a base class. Rust, sadly, is not reasonable in this way.
To make this work in Rust, do the following:
define a coordinator::common::Coordinator trait, where we put common functionality
define a coordinator::common::Fields trait, which has accessors for common fields
common::Coordinator is a subtrait of common::Fields, which gives it access to needed fields
fire::Coordinator will then impl both common traits, with some boilerplate to connect its data fields to the trait (this can be replaced by a macro)
frost::Coordinator will do the same as fire::Coordinator. If they use a macro then they will actually manage to inherit code from the base trait in a reasonably sane way
The original
frost::Coordinatorprovided basic functionality, but the newfire::Coordinatordoes much more in terms of handling timeouts etc, even without the byzantine handling.In a reasonable OO language, it would be trivial to pull the common code into a base class. Rust, sadly, is not reasonable in this way.
To make this work in Rust, do the following:
coordinator::common::Coordinatortrait, where we put common functionalitycoordinator::common::Fieldstrait, which has accessors for common fieldscommon::Coordinatoris a subtrait ofcommon::Fields, which gives it access to needed fieldsfire::Coordinatorwill then impl bothcommontraits, with some boilerplate to connect its data fields to the trait (this can be replaced by a macro)frost::Coordinatorwill do the same asfire::Coordinator. If they use a macro then they will actually manage to inherit code from the base trait in a reasonably sane way