[jira] [Created] (THRIFT-5559) Processor can be implemented on handler trait itself

["Francisco Ayala (Jira)" <ji...@apache.org>]

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)