Are Handlers intended to be returned?

[mschuchard]

I have a question about the intended usage of the Octocrab handlers. I want to create a function for wrapping the IssueHandler<'_> constructor (PoC below):

pub fn new_issues<'octo>(pat: Option<String>, owner: &str, repo: &str) -> Result<octocrab::issues::IssueHandler<'octo>, ()> {
    // instantiate client
    let client = match pat {
        Some(pat) => octocrab::Octocrab::builder()
        .personal_token(pat)
        .build()
        .unwrap(),
        None => octocrab::Octocrab::default(),
    };
    // initalize and return issues
    return Ok(*client.issues(owner, repo))
}

Of course since IssueHandler<'_> does not impldement Deref I cannot seem to avoid the E0515 issue. This leads me to believe that the intended usage for Handler is that they should not be returned.

Is there any documentation that I can be directed towards or added to Octocrab about their intended usage to confirm or deny the intention here? If they are not intended to be returned, is there documentation for something similar in Octocrab that can be returned for functionality analogous to the above?

(documentation label implied for this issue)

[XAMPPRocky]

Thank you for your issue! I moved this to discussions, since it is more of a question.

Handlers are meant to be short-lived, you're supposed to consume them immediately. I'm not sure what you're trying to do with the Deref, but you'll also run into lifetime issues as the octocrab client you construct in the match statement needs to outlive the handler.

Can you provide more detail on what you're trying to achieve?

[mschuchard]

Indeed a question, and this is the first repo I have encountered with a "discussions" so I was unfamiliar with it.

I am attempting to construct a general octocrab::issues::IssueHandler<'octo> and then utilize it for specific actions related to the Issues API by passing it into other functions as a pointer. This is a common design pattern for SDK bindings usage in other languages, and so I was attempting to copy that pattern here (perhaps sub-optimally).

If I cannot return it from a wrapped constructor, then I assume that I would need to either reconstruct the same object repeatedly (inefficient), or wrap both the constructor and the other Issue API functions within a general function (awkward usage).

Is there some better design pattern here?

[XAMPPRocky]

Well I'm not sure about passing the function as a pointer, but I would probably use closures instead. If you know what the return type will be, you can replace I with that type.

pub fn new_issues<I, F>(
    pat: Option<String>, 
    owner: &str, 
    repo: &str,
    customise: impl FnOnce(octocrab::issues::IssueHandler) -> F
) -> Result<I, ()>
    where F: Future<Output = Result<I, ()>>
{
    // instantiate client
    let client = match pat {
        Some(pat) => octocrab::Octocrab::builder()
        .personal_token(pat)
        .build()
        .unwrap(),
        None => octocrab::Octocrab::default(),
    };
    // initalize and return issues
    return (customise)(client.issues(owner, repo)).await
}

let issue: Issue = new_issues(None, "XAMPPRocky", "octocrab", |handler| {
      handler.get(1)
}).await.unwrap();

[mschuchard]

Ok that solution is definitely too clever for someone like me with my too broad/unspecialized of a skill set. I understand the generic can totally be replaced, but using a lambda/closure like that as a parameter to maintain the lifetime is something I probably never would have figured out. I do recognize that this is totally a Rust design pattern so I clearly need to be in that "headspace" more.

Please allow me to progress a bit more as I am still in the PoC phase so I am unsure yet if this completely solves my use case or not. Thank you.

[XAMPPRocky]

using a lambda/closure like that as a parameter to maintain the lifetime is something I probably never would have figured out

No worries, everyone has to learn at some point. In general if you need to control the lifecycle of an operation, for example, if you need to run some code after the caller operations finishes. A closure is the only way in Rust to do that for synchronous operations (async is a bit different with futures, but the principle is the same.)

[mschuchard]

Ok I put some more effort into this and have some takeaways:

• I refactored from robust functionality into limited and simple usage direct from the documentation examples and am still slamming into Rust issues preventing compilation, and so I will need to ensure the usage is as limited and simple as possible if I am developing my plugin with Rust instead of another language.
• I respect this SDK a lot more now and understand better why so few are developed in Rust. Conversely I am unsure why so many are developed in Go and Python, but it appears I will need to continue developing heavily in those two languages for some time to come with all the SDK work I do.
• This experience reminds me of Go several years ago, so I would definitely return to a Rust SDK in the future since Go eventually worked itself out. On a personal note I see Rust more as a successor to Go anyway than C++ (although the power and complexity are similar to me) and do not comprehend all the arguments in the Rust vs. C++ space too.

Thanks again for the help. I will definitely continue attempting to develop the plugin with this SDK but in a much more limited capacity.

Also I totally understand where GH discussions are better suited than SO Q&A so thanks for enabling this in your repo.

[XAMPPRocky]

I don't have the context of what you're trying to make, but just from your previous example, I think you're making it harder for yourself by creating the client inside the function, you'd have a lot easier time exposing the client directly, or by wrapping it in a Context object or similar and have your users pass that around to your SDK functions.