Skip to content
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

Open
wants to merge 70 commits into
base: dev
Choose a base branch
from

Conversation

HenningNT
Copy link
Contributor

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.

HenningNT and others added 30 commits December 12, 2017 13:23
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
- 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?
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 changes from upstream master
Changes some internal to public.
@HenningNT
Copy link
Contributor Author

@nblumhardt I'd really like your opinion about this one :-)

@nblumhardt
Copy link
Collaborator

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!

@HenningNT
Copy link
Contributor Author

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.
After the new syntax has been fully deployed and tested, the old could be labeled deprecated, and after a time removed.

If the team @dotnet-state-machine/reviewers is OK with it?

@HenningNT HenningNT marked this pull request as draft February 6, 2021 10:20
@ffMathy
Copy link
Collaborator

ffMathy commented Aug 24, 2022

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.

@ffMathy ffMathy marked this pull request as ready for review August 24, 2022 04:21
@HenningNT
Copy link
Contributor Author

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...

@leeoades
Copy link
Contributor

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?
If at some point everyone is using one of the different fluent interfaces then it could be considered then making it the default?
Alternatively, keeping them separate offers consumers choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants