Open bvssvni opened 9 years ago
Could design the API as methods on traits inheriting OfBackend
. A Resources
trait could associate types that are shared between backends. These are not part of the closed type family, so at least one argument or the object must be part of the family.
The benefit of this approach is that traits can be declared with their associated types. The Backend
implementation connects the types to each other.
Alternative is a way to convert a type T
outside the family into a type U
inside the family. Could do this by implementing AsRef<U> for T
and AsMut<U> for T
, but this requires std::mem::transmute
.
This could be made easier by extending the backend_impl!
macro.
backend_impl!(
TheSimpons {
Father = GrownUps,
// generates a type `Mother` and `AsRef<Mother> for GrownUps`.
Mother <= GrownUps,
}
);
A library A uses
backend!
and you have libraries B1, B2 etc. that usesbackend_impl!
.How should the API in A be designed such that it allows passing parameters of types that might be shared between B1, B2 etc.?
This problem is relevant when you want the usage of the library to feel seamlessly integrated with the API that B1, B2 etc. depends on. The backend library requires all types in the family to be declared in the same crate when the implementation and
Backend
trait are separate.