publish_own_name (calls publish_name passing the sbots own id as the id)
publish_own_descrption (calls publish_description passing the sbots own id as the id)
get_description (same implementation as get_name)
This PR adds three methods to sbotcli:
- publish_own_name (calls publish_name passing the sbots own id as the id)
- publish_own_descrption (calls publish_description passing the sbots own id as the id)
- get_description (same implementation as get_name)
/// * `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
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```
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 and regex_finder returned Ok. This is why I originally chose to return a Result<Option<String>, SbotCliError>; a None value represents a failure to obtain the id 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 in gosbot for the whoami 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"
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 and `regex_finder` returned `Ok`. This is why I originally chose to return a `Result<Option<String>, SbotCliError>`; a `None` value represents a failure to obtain the `id` 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 in `gosbot` for the `whoami` 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?
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 the whoami call is successful. Error approach is fine by me 👍
Clear to merge 🟢
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 the `whoami` call is successful. Error approach is fine by me 👍
Clear to merge 🟢
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.
glyph
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 forHmm this is a bit clumsy. Might be better as:
/// * `id` - A string slice representing the id (profile reference / public key) of the profile being namedOr:
/// * `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 errorNone => {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
whoamicall was executed successfully andregex_finderreturnedOk. This is why I originally chose to return aResult<Option<String>, SbotCliError>; aNonevalue represents a failure to obtain theidand 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 ingosbotfor thewhoamimethod.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
Optionwill 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 thewhoamicall is successful. Error approach is fine by me 👍Clear to merge 🟢