[ https://issues.apache.org/jira/browse/THRIFT-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523041#comment-17523041 ]
Jens Geyer commented on THRIFT-5559: ------------------------------------ [~allengeorge] ? > 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 > Priority: Major > > 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)