Francisco Ayala created THRIFT-5559: ---------------------------------------
Summary: Processor can be implemented on handler trait itself Key: THRIFT-5559 URL: https://issues.apache.org/jira/browse/THRIFT-5559 Project: Thrift Issue Type: Proposal Components: Rust - Compiler Reporter: Francisco Ayala Right now the compiler produces code of the following form: {code:java} 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) } } {code} 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: {code:java} 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, ) } }{code} 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? -- This message was sent by Atlassian Jira (v8.20.1#820001)