[
https://issues.apache.org/jira/browse/THRIFT-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523264#comment-17523264
]
Allen George commented on THRIFT-5559:
--------------------------------------
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)
