Details
-
Proposal
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Right now the compiler produces code of the following form:
pub trait ServiceSyncHandler {
fn handle_test_episode(&self, arg: types::Type1) -> thrift::Result<types::Type1>;
}
pub struct ServiceSyncProcessor<H: ServiceSyncHandler> {
handler: H,
}
impl <H: ServiceSyncHandler> ServiceSyncProcessor<H> {
pub fn new(handler: H) -> ServiceSyncProcessor<H> {
ServiceSyncProcessor {
handler,
}
}
fn process_test_episode(&self, incoming_sequence_number: i32, i_prot: &mut dyn TInputProtocol, o_prot: &mut dyn TOutputProtocol) -> thrift::Result<()> {
TServiceProcessFunctions::process_test_episode(&self.handler, incoming_sequence_number, i_prot, o_prot)
}
}
There is this object called "ServiceSyncProcessor" which wraps the actual handler. However it has no other fields, and also only ever utilizes a reference to the handler. Thus my question is why aren't the methods implemented on the type itself? Like this:
impl dyn ServiceSyncHandler {
fn process_test_episode(
&self,
incoming_sequence_number: i32,
i_prot: &mut dyn TInputProtocol,
o_prot: &mut dyn TOutputProtocol,
) -> thrift::Result<()> {
TServiceProcessFunctions::process_test_episode(
self,
incoming_sequence_number,
i_prot,
o_prot,
)
}
}
In my case this is limiting since I don't want the server to take ownership of the processor object, since I'm doing everything in a single thread and need this object for other purposes. It was easy enough implementing my own server, but this is now blocking me.
My questions are thus: Is there a reason for this design? Would implementing the alternative I proposed be a welcome addition?
Attachments
Issue Links
- links to
