Comments (7)
What you’re describing is called a choice pseudo state (as described here http://www.uml-diagrams.org/state-machine-diagrams.html#choice-pseudostate).
As you point out a conditional transition is different from a choice pseudo state. I concur your choice for a name different to :if/:unless
. Maybe :choice
?
What is unclear in your proposed syntax is how the array maps to truth values of the condition. If you decide to implement this you should also think ahead about having more than two results and handling the else
case when none of the conditions are met.
Another way to implement this kind of behaviour is to define different events for each condition, This could be the pragmatic solution, although it means not all behaviour is defined in the state machine.
Op 18 mei 2014, om 22:45 heeft Piotr Murach [email protected] het volgende geschreven:
@kjwierenga As requested in this issue I came around to think that this should be implemented. My current thoughts on semantics would be to allow specifying branch states as an array, like so:
event :next, :company_form => [:agreement_form,:promo_form],
if: -> (registrant, user) { user.has_promo? }
Depending on the event condition we would choose appropriate state. One important question to ask is how to distinguish between event conditional logic and state condition. Currently the :if/:unless allow you to guard the transition, that is, ensure the transition succeeds or fails. However, the branching condition would allow to choose between possible states, e.i. it would always succeed. One suggestion would be to use another key argumentevent :next, :company_form => [:agreement_form,:promo_form],
branch: -> (registrant, user) { user.has_promo? }
Any thoughts?—
Reply to this email directly or view it on GitHub.
from finite_machine.
I like the word :choice
, especially for multiple conditions. Tentatively, I would propose to do
event :next do
choice :company_form => :agreement_form, :if ....
choice :company_form => :promo_form, :if ....
choice :company_form => :official_form, :if ....
default :promo_form
end
The first condition that matches is the transition that is performed. Otherwise the default state is set. This would mean the if/unless
can be reused in the conditional pseudo state implementation. Thoughts?
from finite_machine.
And how would this look if I didn’t want to use a block? Or should you move the from state (:company_form
) outside the block?
Op 19 mei 2014, om 15:01 heeft Piotr Murach [email protected] het volgende geschreven:
I like the word :choice, especially for multiple conditions. Tentatively, I would propose to do
event :next do
choice :company_form => :agreement_form, :if ....
choice :company_form => :promo_form, :if ....
choice :company_form => :official_form, :if ....
default :promo_form
end
The first condition that matches is the transition that is performed. Otherwise the default state is set. This would mean the if/unless can be reused in the conditional pseudo state implementation. Thoughts?—
Reply to this email directly or view it on GitHub.
from finite_machine.
Well sir you are driving a hard bargain
event :next, from: :company_form do
choice to: :agreement_form, :if ....
choice to: :promo_form, :if ....
choice to: :official_form, :if ....
default :promo_form
end
I'm in favour of block as I wounldn't like people using loads of hash options for event specification. I think readability is important and enforcing it through this specific block case would be appropriate?
from finite_machine.
I was hoping you would come up with this. This syntax removes the duplication and ambiguity. Nice!
The syntax with :from prohibits the use of :from as a state name just like with normal transitions.
Op 19 mei 2014 om 23:46 heeft Piotr Murach [email protected] het volgende geschreven:
Well sir you are driving a hard bargain How about if we do this
event :next, from: :company_form do
choice to: :agreement_form, :if ....
choice to: :promo_form, :if ....
choice to: :official_form, :if ....
default :promo_form
end
I'm in favour of block as I wounldn't like people using loads of hash options for event specification. I think readability is important and enforcing it through this specific block case would be appropriate?—
Reply to this email directly or view it on GitHub.
from finite_machine.
I've implemented the choice pseudo state with agreed semantics. The added benefit is that you don't have to use the choice DSL, you can resort to using plain events syntax. Thank you for the contribution!
from finite_machine.
This worked out nicely. Well done! Thanks.
from finite_machine.
Related Issues (20)
- Remove on_transition callback HOT 5
- Cancelling inside callbacks HOT 3
- Consider removing the conversion of event names into methods. HOT 1
- Repo description url is broken HOT 1
- Website for the gem is not working HOT 1
- Terminal state HOT 4
- When an error occurs on transition the current state is not "rollback" HOT 2
- https://travis-ci.org/minad/moneta
- Ruby 2.6.0 support (ruby-2.6.0-preview3) HOT 1
- Defining helper methods on machine, not on target HOT 2
- Setting target that responds to to_hash HOT 1
- v0.12.1 missing sync dependency HOT 4
- Java::JavaUtilConcurrent::RejectedExecutionException on jruby HOT 1
- Message Queue Spec sometimes hangs on jruby HOT 2
- alias_target doesn't seem to work HOT 2
- [ Feature Request ] Handling For Multiple State Machines HOT 3
- Unable to define constructors on custom classes HOT 4
- Base class events are not overrided in subclass.
- Errors with Ruby 3.1.2 HOT 2
- Transition does not happen if any_state is used in the definition. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from finite_machine.