Closed Boscop closed 3 years ago
I've wanted to do this for so long. It is very unergonomic indeed.
It's a breaking change, since it now requires plugins to implement new
, but most non-trivial plugins probably do that anyway, and it's very easy to adapt a plugin that doesn't.
We could consider, as a next step, removing the Default
implementation for HostCallback
, which was really only there to make it slightly less unergonomic to implement Default
for a Plugin
. This would save the check for the callback being initialized on every call and statically guard against that panic situation.
Review for PR coming up...
@askeksa Yes, good point. Having HostCallback
not Default
also eliminates the possibility of forgetting to initialize it in new()
.
The fact that a plugin has to be
Default
makes it very unergonomic, especially if the plugin state contains many types that aren'tDefault
, which are initialized innew()
(such asSender
/Receiver
), requiring wrapping them inOption
etc.Plugin::new
only requiresDefault
becausePluginInstance
implsPlugin
but doesn't impl thePlugin::new
method (PluginInstance
is notDefault
)!PluginInstance
has an inherentnew
method with a different signature:fn new(effect: *mut AEffect, lib: Arc<Library>) -> PluginInstance
.The options we have is to either impl
Plugin::new
forPluginInstance
(it is never called anyway, (becausePlugin::new
is only called on the client side, butPluginInstance
is only used on the host side), so we could just useunreachable!()
) or moving thenew
method fromPlugin
into a newtrait PluginWithNew: Plugin { fn new(host: HostCallback) -> Self; }
.