for now I code in quick and dirty, but I will maybe have a bunch of hours this week to minimize my SAM implementation. And maybe have a POC of this future NAP action composition.
is this basically nap() implemented component-wise using inversion of control?
I am not sure what you mean.
I am working on the refactoring of my SAM implementation. I am still a the naming step.
I still struggle on the word State.
As you wrote:
Unintuitively, the State does not hold any “state”,
It is unintuitive. And I concur :) So why call it like that ? I can get that it could be linked to the state machine control state, but as you wrote:
SAM does not require the State implementation to be based the semantics of a state machine
So what it the reasons behind this name?
In your comparison between Redux+React and SAM you say:
View is a function of the state | State representation is a function of the model
Below comes from Design Patterns: Elements of Reusable Object-Oriented Software and they describe how a pattern should be described. These things are not very clear/organized on the website and help others decide to use/try out a pattern. There is too much information on the internet the go through so it must be easy for any new user to pick and try out a pattern.
1.3 Describing Design Patterns
How do we describe design patterns? Graphical notations, while important and useful, aren’t sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. Concrete examples are important too, because they help you see the design in action.
We describe design patterns using a consistent format. Each pattern is divided into sections according to the following template. The template lends a uniform structure to the information, making design patterns easier to learn, compare, and use.
Pattern Name and Classification
The pattern’s name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. The pattern’s classification reflects the scheme we introduce in Section 1.5.
A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?
Also Known As
Other well-known names for the pattern, if any.
A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.
What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations?
A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique (OMT) [RBP+91]. We also use interaction diagrams [JCJO92, Boo94] to illustrate sequences of requests and collaborations between objects. Appendix B describes these notations in detail.
The classes and/or objects participating in the design pattern and their responsibilities.
How the participants collaborate to carry out their responsibilities.
How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?
What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?
Code fragments that illustrate how you might implement the pattern in C++ or Smalltalk.
Examples of the pattern found in real systems. We include at least two examples from different domains.
What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?