Hello All,
I'm trying to make a functional task management application and wanted some help with how one would implementing a queueing system between different application structs.
The Why: currently, I simply have a tasklist which holds a vec of my task struct. This conforms to standard OO practices, with a small functional twist. users have a set of public functions to update task state without actually mutating the underlying structure.
- I do this by returning a completely new struct, only with the modification applied. this applies to both my task struct, as well as the task list struct, allowing me to only every need a reference to actually update the structs.
- However, my tasklist struct simply calls the functions within the task struct, creating a loose coupling between the two structs. This is important because in my vision of the task manager, a user could potentially only use the task struct, without wanting to wrap it in a task list struct were they to only use the library.
I want to implement message queuing between internal structs like my task struct to its' overall TaskList struct, so that my task struct has a generic way to return modifications, wether it is being called by TaskList, Another rust crate, or even another language, I feel a message queue is the best generic way to alter a struct in a functional, generic way.
However, crate like queen - crates.io: Rust Package Registry seem much more focused on external message queues like HTTP requests.
How can I easily implement a message queue between my objects such that a process flow can be designed around these queues rather than raw function calls?
my initial thought would be to create a new queue struct which would recieve messages from TaskList, and ferry them to Task. but this leaves several questions.
- do I need a new queue for each task? if so, how can I make a queue that could easily modify the correct Task in a collection?
- what should I return once i've completed my transformation? this issue could be solved using mutable state again, but I want to avoid that as much as possible so I can maintain a functional look-and-feel for the crate. I'm not sure if it is bad practice to send messages consisting of entirely new objects but I can't really see a way around this when the application in question (I have a CLI to start with) needs the NEW list that it is expecting from sending the modification request.
- Finally, how do I properly flow information such that the tasks "read" the new messages in a pro-active way? I want to be asynchronous so simply calling a "read_message()" function seems counter-productive to my goals.
I know this is allot and I don't expect a full, detailed answer, but I just wanted to know if anyone else has experienced this conundrum and if there were any ideas for robust data flows around this need.
As always, thank you for reading this and thank you for your time and expertise!
Edit:
I wanted to include a minimal example of what i currently have so I made a playground link: Rust Playground
This is a minimal example of how i'm working with the structure. It is pretty standard OO design, the only difference is that playground doesn't allow the im crate so I had to do a slight mutation witihin the parent function.
What I want to call attention to though is the coupling that occurs between Parent and Child when altering a specific one. We have to call the function directly, cousing a coupling between the parent and the child (this is important because in this scenario parent might be the only thing that wants to have a Child struct)