-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Even more fluent syntax #369
base: dev
Are you sure you want to change the base?
Even more fluent syntax #369
Conversation
Updated DOT graph section, so it no longer refers to missing ToDotGraph method.
Add Parameterized Guard Clauses to PermitIf as optional arguments. Arguments passed into guard(s) must match the arguments of the TriggerWithParameters associated with the transition. - Change GuardCondition to use Func<object[], bool>. - Add Unit Tests. Failing Unit Test: - Stateless.Tests.DotGraphFixture.WhenDiscriminatedByNamedDelegate - Stateless.Tests.ReflectionFixture.TransitionGuardNames - Stateless.Tests.ReflectionFixture.WhenDiscriminatedByNamedDelegate_Binding
Add new guard condition constructor that accepts a No Argument Guard condition so that we can preserve the initial method description. Convert to Func<object[],bool> much later than in StateConfiguration. We wrap no argument guard descriptions in a lambda so it can be passed in as a Func<object[], bool>, however this had the side effect of ruining reflection and graph processes as the original description of the method was lost during this conversion. Unit Tests Now Passing: - Stateless.Tests.DotGraphFixture.WhenDiscriminatedByNamedDelegate - Stateless.Tests.ReflectionFixture.TransitionGuardNames - Stateless.Tests.ReflectionFixture.WhenDiscriminatedByNamedDelegate_Binding
- IgnoreIf - PermitDynamicIf
- Add Permit*If unit tests for multiple guards. - Fix Naming. - Add Negative Cases.
Added a bit of detail about guards.
Re-Add publicly accessible guard checks in order to support backwards compatibility. These new versions just call the new robust check with zero arguments.
Update actual trigger behavior results to evaluate instantly by just adding a ToArray(). If a IEnumerable with processing, like a Select(), is kept that way, it will only go through that processing once it's enumerated. This causes the guard conditions of transitions to be evaluated twice, which was a waste of everybody's time.
Fix issue caused by weird merge?
…causing problems for appveyor.
Removed install section. It installed .net core, which is already included in the Visual Studio 2017 image. Validated yaml file at ci.appveyor.com
…tGraph output." Doing this since upsream has been fixed, and conflicts with this fork. This reverts commit 67979f9.
Pick up from upstream
Pick up changes from upstream master
Changes some internal to public.
@nblumhardt I'd really like your opinion about this one :-) |
Some nice features in the new syntax, @HenningNT 👍 ... the main downside would be the tradeoff between accumulating redundant code/inconsistent API naming ("permit" a trigger vs. "transition" on a trigger), and breaking changes. Unsure which I'd choose, there's some merit to keeping things moving forward and trimmed-down 🤔 I'm still low on time to contribute here, so apologies for not digging in deeper - good luck with it! |
I considered using Permit, but I think it's better to change the name to Transition since it's a new syntax with different functionality. This way the confusion should be reduced somewhat. I would like to remove the "old" syntax, and only use the "new". There would be a transition period where the old and new syntax would haver to co-exist. If the team @dotnet-state-machine/reviewers is OK with it? |
…> guard, string guardDescription = null) Added relevant If(...)
Removed async parts. Removed fireing mode
I think this is awesome! @HenningNT is this completed? Because if so, I can merge it for you. And if not, I can finish it for you. |
I think it is complete, all the tests pass... But it is a completely new syntax, so it would be a new major version number. I was unsure what to do with it... |
Fyi - I developed a different fluent interface that I found easier to understand as a set of extention methods and builder classes. Under the hood, they call into the unchanged stateless interface. My plan is to release it as its own package, basically making it optional. It also allows me to document the different interface without muddying the water here. Perhaps the same approach could be used here? |
Added a more flexible, generic fluent syntax.
Also added an optional Action to the transitions.
I took inspiration from PR #173, and added what I thought would work.