Fairly simple change that gives us more flexibility when calling sbot::init() by allowing the ip_port and net_id parameters to be passed as Option<String> or Option<&str>.
This makes it possible to define const values for the parameters required by sbot::init(), for example:
@notplants What do you think? I'm happy to make the required changes to peach-web and peach-config, along with the various documentation, but wanted to check-in with you because this represents a breaking change.
This was prompted by my work on lykin, specifically wanting to be able to quickly define a custom port for go-sbot.
Fairly simple change that gives us more flexibility when calling `sbot::init()` by allowing the `ip_port` and `net_id` parameters to be passed as `Option<String>` or `Option<&str>`.
This makes it possible to define `const` values for the parameters required by `sbot::init()`, for example:
```rust
const KEYSTORE: Keystore = Keystore::GoSbot;
const IP_PORT: Option<&str> = Some("127.0.0.1:8021");
const NET_ID: Option<&str> = None;
```
Then any `sbot` initialisation can reuse those values:
```rust
let mut sbot = Sbot::init(KEYSTORE, IP_PORT, NET_ID)
.await
.map_err(|e| e.to_string())?;
```
The downside is that `None` parameters need to be annotated when the function is called. For example:
```rust
Sbot::init(Keystore::CustomGoSbot(key_path), None::<&str>, None::<&str>).await?
```
Notice the `None::<&str>` annotation.
@notplants What do you think? I'm happy to make the required changes to `peach-web` and `peach-config`, along with the various documentation, but wanted to check-in with you because this represents a breaking change.
-----
This was prompted by my work on `lykin`, specifically wanting to be able to quickly define a custom port for go-sbot.
Interesting, it seems like a natural thing to want to be able to define, but that None::<&str> syntax is pretty bizarre. But it seems like thats the way to do "optional" arguments in rust so looks good.
Then any sbot initialisation can reuse those values:
fwiw, the pattern I would probably use in the application code is to define a separate utility function with no arguments init_sbot(), which calls Sbot::init(KEYSTORE, IP_PORT, NET_ID) inside of it, rather than calling Sbot::init in multiple places passing the same constant arguments (and thus avoiding the code duplication of needing the same arguments to be passed)
Interesting, it seems like a natural thing to want to be able to define, but that None::<&str> syntax is pretty bizarre. But it seems like thats the way to do "optional" arguments in rust so looks good.
> Then any sbot initialisation can reuse those values:
fwiw, the pattern I would probably use in the application code is to define a separate utility function with no arguments init_sbot(), which calls Sbot::init(KEYSTORE, IP_PORT, NET_ID) inside of it, rather than calling Sbot::init in multiple places passing the same constant arguments (and thus avoiding the code duplication of needing the same arguments to be passed)
Haha yeah the turbofish is definitely one of the weirder pieces of Rust syntax.
the pattern I would probably use in the application code is to define a separate utility function with no arguments init_sbot(), which calls Sbot::init(KEYSTORE, IP_PORT, NET_ID) inside of it
Perfect, thanks for the tip. I'll do that.
I'll get some other PR's ready before merging this.
Haha yeah the turbofish is definitely one of the weirder pieces of Rust syntax.
> the pattern I would probably use in the application code is to define a separate utility function with no arguments init_sbot(), which calls Sbot::init(KEYSTORE, IP_PORT, NET_ID) inside of it
Perfect, thanks for the tip. I'll do that.
I'll get some other PR's ready before merging this.
You are not authorized to merge this pull request.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
notplants
Fairly simple change that gives us more flexibility when calling
sbot::init()by allowing theip_portandnet_idparameters to be passed asOption<String>orOption<&str>.This makes it possible to define
constvalues for the parameters required bysbot::init(), for example:Then any
sbotinitialisation can reuse those values:The downside is that
Noneparameters need to be annotated when the function is called. For example:Notice the
None::<&str>annotation.@notplants What do you think? I'm happy to make the required changes to
peach-webandpeach-config, along with the various documentation, but wanted to check-in with you because this represents a breaking change.This was prompted by my work on
lykin, specifically wanting to be able to quickly define a custom port for go-sbot.Interesting, it seems like a natural thing to want to be able to define, but that None::<&str> syntax is pretty bizarre. But it seems like thats the way to do "optional" arguments in rust so looks good.
fwiw, the pattern I would probably use in the application code is to define a separate utility function with no arguments init_sbot(), which calls Sbot::init(KEYSTORE, IP_PORT, NET_ID) inside of it, rather than calling Sbot::init in multiple places passing the same constant arguments (and thus avoiding the code duplication of needing the same arguments to be passed)
Haha yeah the turbofish is definitely one of the weirder pieces of Rust syntax.
Perfect, thanks for the tip. I'll do that.
I'll get some other PR's ready before merging this.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.