To Callback or not to callback

callback seems fine for this.

or just in the command that needs it, have an additional member variable such as m_command_has_executed with a get_has_command_executed() member function. Have the original object that created the command maintain a reference to the command. On the next tick when the object runs its update() method, have it check the last_enqueued_command->get_has_command_executed() to see if it already ran. but don't see how that is really any much better than a callback function. just another way.

Seems like there are some other potential concerns, such as object lifetimes. Some languages and tools are better suited at this than others, but there are important details like making sure the objects involved are all still valid when commands are run.

I've worked with container-style systems where objects in the container can have their function called at specific future points in time, such as before/after processing, before/after rendering, before/after physics. It is more special purpose than you described, but has the benefit of letting the container verify the object is still alive before calling the function.

I've also seen many event bus systems allow for delayed events to be broadcast. A system can register an event listener and fire a timed event. If the target object is still alive the object's listener can respond, if the object has died it will have been de-registered as a listener so no problems from running a callback on dead objects.

For the specific problem you're facing a message bus sounds ideal. The original object can indicate it needs an event with a specific unique ID. The system can listen for the event, and if the unique ID matches it can do the work it had delayed. The system may need other protections, such as killing off long-overdue tasks, but the message bus pattern solves all kinds of inter-object communications issues.

On 12/24/2017 at 9:10 AM, Munchkin9 said:

The solution I found is to embed a callback parameter into EnquedCommand and have that passed through the queues so that the callback is called when the command is run. What I don't like about the solution is that this requires a fair bit of refactoring

Commands are functions, right? If they already perform work then why does anything need to be refactored? Perform the callback within the normal work of the command's function, or wrap the command with a command which calls the original command THEN the callback, if that makes more sense. Imagine this pattern, but adapted to whatever additional complexities you require (IPC, RPC, etc).

Action WrapAction(Action command, Action callback)
{
  return () =>
  {
    command();
    callback();
  };
}

If you're dealing with IPC then you will definitely need some way of handling responses and completion which can deal with the callback. It's not overkill. If you're NOT dealing with IPC then do you really need all those intermediate objects and queues?