Add publish_own_name, publish_own_description, get_description #6
No reviewers
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/go-sbotcli-rs#6
Loading…
Reference in New Issue
No description provided.
Delete Branch "publish_own_name"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR adds three methods to sbotcli:
Ace, I love these new self-oriented methods! I've left two comments for you.
@ -348,3 +377,3 @@
///
/// * `name` - A string slice representing a profile name (bio)
/// * `id` - A string slice representing an id (profile reference / public key)
/// * `id` - A string slice representing a id (profile reference / public key) of who the name is for
Hmm this is a bit clumsy. Might be better as:
/// * `id` - A string slice representing the id (profile reference / public key) of the profile being named
Or:
/// * `id` - A string slice representing the id (profile reference / public key) of the one being named
@ -452,0 +518,4 @@
},
// if the regex does not match, then return an error
None => {
Err(SbotCliError::WhoAmI("Error calling whoami: regex not matched".to_string()))
I'm in two minds about returning an error for the no-capture condition. It's technically not an error, since the
whoami
call was executed successfully andregex_finder
returnedOk
. This is why I originally chose to return aResult<Option<String>, SbotCliError>
; aNone
value represents a failure to obtain theid
and the caller must match accordingly.With that being said, I think it's extremely unlikely that we fail to capture the
id
. That would only happen if our regex pattern were incorrect or if there was a low-level error ingosbot
for thewhoami
method.If we stick with the current error approach, I'd recommend making the message more specific:
"Error calling whoami: failed to capture the id value using regex"
imo an error is technically not just when an underlying call returns an error, but whenever a function fails to do what you want it to do, however you define that.
To me it makes the most sense to define that if this function is working it returns an id, and if it doesn't then it returns an error, because I can't think of a case where sbot is working but you wouldn't have an id from whoami, and defining it in this way makes it easier for the caller to use in most use cases where the ID is really what they want.
Returning an Option feels to me like creating unnessesary work. Or is there a case where whoami should return None?
Agreed that the
Option
will create unnecessary work for the caller and may result in confusion. Also agreed that the ID value should always be returned from the sbot if thewhoami
call is successful. Error approach is fine by me 👍Clear to merge 🟢