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

["Jens Geyer (Jira)" <ji...@apache.org>]

    [ 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)