InstanceFeatures then offers a few methods that all contain &self.
In Rust, I can easily make a trait object out of InstanceFeatures, but not out of InstanceInit.
In our code, we need to keep track of an assortment of different plugins and then instantiate them at runtime, depending on user input.
Currently we're doing that by requiring that all plugins implement both traits and manually unpacking the init-trait into a struct of
Is there a more idiomatic way to do this?
I understand that I can't create a trait object by just doing Box::new(Plugin) for a struct Plugin that implements InstanceInit and InstanceFeatures, but the current way we're doing this seems a bit convoluted.
If you want dynamic dispatch for a trait that's not object-safe, there is a trick you can use: Define a second, object-safe, trait with a blanket implementation for everything that implements the non-object-safe one.
A first cut of what your API might look like with that technique is below. Plugin authors would implement Plugin and Builder and your dynamic code uses Box<dyn DynPlugin> and Box<dyn DynBuilder>. The Plugin objects will probably be unit structs and the Builders correspond to your InstanceInit.
is pretty similar to a vtable of a trait object (except that there’s no self parameters). It could have a method so that you can build it with PluginInit::new::<MyPlugin>(). E.g.
fn main() -> Result<(), Box<dyn Error>> {
let initializer = PluginInit::new::<MyPlugin>();
// ...
let params = initializer.get_default_parameters();
let _plugin = initializer.initialize(params)?;
Ok(())
}