More intuitive calls to BotLock #77

Open
opened 2024-04-09 14:12:37 -04:00 by modulatingforce · 2 comments

At the moment, there are areas that call botlock in a way that isn't very intuitive to custom developers . At the moment, custom developers aren't necessarily asked to drop() locks/guards, even though they are implicitly dropped at the end of a block

https://git.flake.sh/modulatingforce/forcebot_rs/src/branch/master/src/custom/experimental/experiment001.rs#L182-L196

let bot = Arc::clone(&params.bot);

let botlock = bot.read().await;

// uses chat.say_in_reply_to() for the bot controls for messages
botlock
.botmgrs
.chat
.say_in_reply_to(
    Channel(params.clone().msg.channel_login().to_string()),
    params.clone().msg.message_id().to_string(), 
    String::from("GoodGirl xdd "),
    params.clone()
).await;

One way we could make this more intuitive is just have some both method or something at ExecBodyParams that will return the lock directly

I think I played around with the ideas before briefly but ran into issues. I'm sure some variation of this is possible though

At the moment, there are areas that call `botlock` in a way that isn't very intuitive to custom developers . At the moment, custom developers aren't necessarily asked to `drop()` locks/guards, even though they are implicitly dropped at the end of a block https://git.flake.sh/modulatingforce/forcebot_rs/src/branch/master/src/custom/experimental/experiment001.rs#L182-L196 ```rust let bot = Arc::clone(&params.bot); let botlock = bot.read().await; // uses chat.say_in_reply_to() for the bot controls for messages botlock .botmgrs .chat .say_in_reply_to( Channel(params.clone().msg.channel_login().to_string()), params.clone().msg.message_id().to_string(), String::from("GoodGirl xdd "), params.clone() ).await; ``` --- One way we could make this more intuitive is just have some both method or something at `ExecBodyParams` that will return the lock directly I _think_ I played around with the ideas before briefly but ran into issues. I'm sure some variation of this is possible though
Collaborator

I thought harus idea was to put this whole block of replying to someone into a method for params. Just returning the lock won't really make it easier to use.

I thought harus idea was to put this whole block of replying to someone into a method for params. Just returning the lock won't really make it easier to use.
Author
Owner

I thought harus idea was to put this whole block of replying to someone into a method for params. Just returning the lock won't really make it easier to use.

Actually that would make it more intuitive yes. And easy to implement

@mzntori So maybe say in reply can be called from params / ExecBodyParams, and remove the bot from that flow ? Yeh I like this as long as the custom developer can access the bot for less commonly accessed methods etc

> I thought harus idea was to put this whole block of replying to someone into a method for params. Just returning the lock won't really make it easier to use. Actually that would make it more intuitive yes. And easy to implement @mzntori So maybe say in reply can be called from params / `ExecBodyParams`, and remove the bot from that flow ? Yeh I like this as long as the custom developer can access the bot for less commonly accessed methods etc
Sign in to join this conversation.
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: modulatingforce/forcebot_rs#77
No description provided.