Please note the main deficiency of all the message handling design patterns: they do not facilitate state dependent handling out of the box. It is more of an afterthought, left to the user(developer) to implement. This applies to the simplest one, DQMH, and Actor Framework. In reality it happens more often than not that you can fall into the following trap. You initially think that you can get away with a particular "module" being stateless and choose the corresponding (stateless) architecture/design for it. Then later you realize that it is indeed stateful, i.e. its reaction to the same input(message, event, call) must indeed vary depending on the value of some variable(s), local (internal, private) to that module. What can (and will you) do most likely? You will branch your code (use case structures) in a haphazard way, maybe in more than one place within the module. This hardly will help you create a readable and modifiable code even if at first it looks like not a big deal. So, the moral is that unless you are absolutely sure that a piece of code (module) you start developing will never become stateful you'd better account for such a possibility from the very beginning by using a design pattern that does allow for such (stateful) behavior. Now what kind of code will facilitate such state dependent behavior? Finite State Machines, Hierarchical Finite State Machines and... something else.
Now please note another aspect, namely what most LabVIEW users know (what NI taught them) about state machines.When talking about state machines NI teaches the simplest Moore automaton as practically THE state machine (they only mention that other types exist). The direct consequence of this is the lack of separation between notions of state and action in the heads of the students, because in the Moore state machine an action can be associated only with entering a state, not with transitions between them. That's why people keep talking about "executing states", "enqueuing states", etc. In reality state includes any data (variable) different values of which can change the behavior, namely, the reaction/response to some input (event, received message). Mealy state machine associates actions with transitions between states and is therefore much more suitable for implementing behavior which is both event-driven ("message handling") AND stateful SIMULTANEOUSLY. Although Mealy and Moore state machines are equivalent in what kind of behavior they can describe/implement, it is also much more natural for a human (programmer) to reason in terms of states, events, and actions ("When this event happens or message is received AND this module is in this state which actions should it run and switch to which state?") rather than only states and events (Moore state machine) or only events/messages and actions (message handlers). I am actually shocked that in 20 years nobody but me and the author of the "state actor" modification for the original AF came up with a Mealy state machine design pattern. My EDQSM implementation of it is just a simple extension of the producer consumer pattern, which in turn is indeed a message handler. In fact, if you Google "LabVIEW Mealy" the only actual code you will find will be my EDQSM. Of course, Mealy state machine (and hence EDQSM) is still prone to the "state explosion" problem for any slightly more than trivial desired behavior. You have to use HFSMs and/or something else to implement anything more complex. But it still goes far beyond DQMH and even the original AF (without "state actors"). Of course, even HFSMs (statecharts) have their limitations (lack of modularity, for example) but for people who seriously consider stateless message handlers as the architecture for their projects that should definitely not be an issue. Well, unless they severely underestimate the actual behavioral complexity needed to be implemented (per the current or future requirements) in their projects.
