dispatch short-circuiting is confusing

[Joshuaalbert]

What's the value of short-circuiting in dispatch? The point of dispatch is to call the trigger in a many-models-single-machine situation. I don't want the arbitrary ordering of the models to affect whether some models are allowed to trigger. I think this is a bug, but if not can someone explain to me the design choice?

    def dispatch(self, trigger, *args, **kwargs):
        """Trigger an event on all models assigned to the machine.
        Args:
            trigger (str): Event name
            *args (list): List of arguments passed to the event trigger
            **kwargs (dict): Dictionary of keyword arguments passed to the event trigger
        Returns:
            bool The truth value of all triggers combined with AND
        """
        return all(getattr(model, trigger)(*args, **kwargs) for model in self.models)

[aleneum]

Hello @Joshuaalbert,

thats a fair point. Results should rather be collected and returned like res = [getattr(model, trigger)(*args, **kwargs) for model in self.models] ... return all(res). Would you say a bool from all(res) is the correct return value or should it be something along the line [bool] (which is also a bit arbitrary) or dict[model, bool]?

[Joshuaalbert]

For parallel models, I think it is pretty irelevant. For parallel states, I would say using any. This is valuable in the "FPGA-like" mindset in designing FSM's. I.e. where you decouple data updates (which are identities), from a singular transition trigger.

def trigger_transition(self, event_data):
  model = event_data.model
  while True:
    if not model.trigger('transition'): # ==> if not any transitions then we're done
      break

In this above snippet, we want all possible transitions to happen in a single "clock cycle". This is particularly useful when you decouple data from a singular transitions trigger.

# Update identities
add_transition(
  trigger='new_img', source="*", dest="=", conditions="is_my_data",
  after=['process_img', 'trigger_transition'] # after update, we do all possible transitions.
)
add_transition(
  trigger='new_sound', source="*", dest="=", conditions="is_my_data",
  after=['process_sound', 'trigger_transition'] # after update, we do all possible transitions.
)

# Transition triggers for single 'transition' trigger
add_transition(
  trigger='transition', source='A', dest='B', conditions=[...],
  after=[...]
)
add_transition(
  trigger='transition', source='B', dest='C', conditions=[...],
  after=[...]
)
...

Sometimes, you can even decouple 'clock cycle' from the update triggers. Then 'trigger_transition' might be invoked by a some poller.

So TLDR; I think any should be used to combine triggers when there are more than one that need to be combined. But, I think this is mostly only useful in parallel states situations, rather than parallel machines.