[ https://issues.apache.org/jira/browse/THRIFT-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523264#comment-17523264 ]
Allen George edited comment on THRIFT-5559 at 4/17/22 2:22 AM: --------------------------------------------------------------- It's been a very, very long time since I've looked at the code as a whole, and I'm doing this off memory but this was probably a consequence of having to support the {{extends}} behavior for Thrift services the the simplest, most robust way for the generator. A service can extend any number of services from any number of Thrift files. Extend hierarchies can also be arbitrarily complex. Methods on those services can have types that themselves have to be resolved in the generated code and may themselves come from multiple files. By defining traits and generating code for them on a per-service basis, the generator only ever has to consider the current file for method declarations. The only place where we have to consider more than a single file is when doing trait inheritance, and that's fairly simple, as I only have to consider the names of the traits being extended, not the methods/types they contain or reference. Finally, the processor itself can just be defined in terms of the extended trait (and again, the generator does not have to care about the methods/types in the arbitrarily complex service extends hierarchy). was (Author: allengeorge): It's been a very, very long time since I've looked at the code as a while, and I'm doing this off memory but this was probably a consequence of having to support the {{extends}} behavior for Thrift services the the simplest, most robust way for the generator. A service can extend any number of services from any number of Thrift files. Extend hierarchies can also be arbitrarily complex. Methods on those services can have types that themselves have to be resolved in the generated code and may themselves come from multiple files. By defining traits and generating code for them on a per-service basis, the generator only ever has to consider the current file for method declarations. The only place where we have to consider more than a single file is when doing trait inheritance, and that's fairly simple, as I only have to consider the names of the traits being extended, not the methods/types they contain or reference. Finally, the processor itself can just be defined in terms of the extended trait (and again, the generator does not have to care about the methods/types in the arbitrarily complex service extends hierarchy). > 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)