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

Natural StateMachines cannot transition on interfaces #60

Open
aidapsibr opened this issue Nov 26, 2018 · 4 comments
Open

Natural StateMachines cannot transition on interfaces #60

aidapsibr opened this issue Nov 26, 2018 · 4 comments
Assignees
Milestone

Comments

@aidapsibr
Copy link
Contributor

When defining a transition between two states in a natural schematic, using an interface appears to work, but at run-time it will never resolve to a valid transition.

REstate Package Versions

9.0.0-preview10

Steps to Reproduce

  1. Add a transition with a interface signal
  2. Send a concrete object casted as that interface
  3. Fails

Expected behavior: Transition succeeds.

Actual behavior: Transition not defined exception is thrown.

Reproduces how often: 100%

@aidapsibr
Copy link
Contributor Author

aidapsibr commented Nov 27, 2018

This is probably not ever going to be supported as it leaves too many open paths on the schematic.

One of the possible ways to address this is to add a generic constraint: where TSignal : class, this would at least make it clear it cannot be an interface. Regarding base classes (and abstract), there aren't really many options here that don't hinder other use cases (such as a new() constraint). I'd just add it as a documentation candidate on the builder method and stop there.

@aidapsibr
Copy link
Contributor Author

Revisiting this, it still sucks. where TSignal : class wont work since that just means is a reference type. I'm getting really close to saying it should be where TSignal : new() to prevent the kinds of major confusion that can happen when you think an action will be invoked, but at run-time it doesn't resolve...

The other solution is to do some run-time checking on the State to see if multiple actions are implemented, INaturalAction<TSignal> or INaturalPrecondition<TSignal> doesn't match the TSignal in INaturalState<TSignal>.

The run-time checking would be useful in either case since base classes can still be an issue here.

@aidapsibr
Copy link
Contributor Author

This is the desired behavior, but there is some inflexibility in limiting what objects can be signals.

image

@aidapsibr aidapsibr added this to the v10 milestone Feb 22, 2020
@aidapsibr aidapsibr self-assigned this Feb 22, 2020
@aidapsibr
Copy link
Contributor Author

@zoeysaurusrex and I tackled this together last night and have a solution that solves about 1/2 of the problems. In the new pattern, you can multiple Actions/Preconditions on states (Yay!!) and it works!. The only issue is one of those could be an interface, if you for instance implement IAcceptSignal<IProvisionedSignal> and IAcceptSignal<ReserveSignal> where ReserveSignal implements IProvisionedSignal, then which action/precondition would execute?.

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

No branches or pull requests

1 participant