I’m posting here because we’ve been stuck on this for a long time. This is on behalf of McBrincie212—we couldn’t get any help on the Rust Discord, so I’m posting it here instead.
Summary
Currently im faced with a problem i've been battling for 2 weeks straight. In my system i have "Tasks" which contains their own TaskFrame, TaskTrigger and TaskHooks (a collection of them). Then i have "Schedulers" which are meant to own Tasks, the problem im faced goes as follows:
"How do I interact with the Task in outside code without holding anything related to the "Scheduler" everywhere, only the identification part of the Task."
For example, suppose a TaskDependency may want to inject its own TaskHooks, hence needs a way to communicate with the Task. Another example is suppose AlertTaskHook may want to fully remove a Task when it sees something... etc.
I have come up with two solutions:
Task / IDs Users assemble a Task<T1, T2> struct where T1 and T2 is the TaskFrame and TaskTrigger respectively. Then you can reference around via &Task<...> before being scheduled but when you need to schedule it on a Scheduler you need the owned part, then it returns an identifier helping you to reference it back via the Scheduler (the identifier is clonable).
[✓] Simple to implement from my side (macros and TaskFrameContext)
[✗] Two different APIs for the same thing
[✗] During the identifier API, you must leak the Scheduler which owns this Task as well which is a bad pattern
[✗] Assumes a specific storage shape mapping an ID to a Task (no flexibility)
TaskHandles Its a similar idea to the above, but the difference is you explicitly tell the Scheduler, the TaskFrame and TaskTrigger to allocate into a Task, then it returns a handle containing the location of the Task along with methods for interacting with it (including Scheduler-based operations).
[✓] Flexibility in how the storage layout is defined
[✓] One unified API
[✗] Difficulty in implementing the macros and TaskFrameContext
Before writing a full explanation about the problem and any clarifications. Do let me know first if anyone is willing to help out with the problem (as to not write an entire manifesto and waste time from ignorance). For the gh issue its not too suffecient to explain everything so if you have any questions, again let me know 100% predicting no one will be interested to help either from the get go or after the full explanation
Unfortunately, people's willingness to help probably depends on how well you can describe the problem in detail, so there is no way to predict without seeing it.
And rather than writing a manifesto and asking for overall design improvements, I suggest trying to show one specific approach you tried and exactly where you ran into a roadblock, including code and errors. Then you'll get concrete suggestions for that specific roadblock.
A witticism I rather like (I forget where I first heard it) is that the fastest way to get help on the internet isn't to ask... it's to post the wrong solution. I've found this to be especially true on programming forums.
