Lukas Renggli

No, not out of the box. Why not use the existing package?

State transitions are initiated programmatically through `someState.enter()`. If you want to condition this you could wrap such code into a method that performs additional checks?

I am definitely open to expand this library, I just don't quite understand the need. Happy to see what can be done, if you could provide a minimally reproducible example?

Looks reasonable. What I don't like is the untyped context it introduces `Map` and that a very clear command like `stateC.enter()`is silently ignored in some cases. I still think it...

I agree, it is unfortunate that the `State` cannot be customized/wrapped. What about changing `newState`, `newStartState`, `newStopState` to something like the following? ```dart S newState(T identifier, {S Function(Machine, T)? constructor})...

What about something along ... ```dart import 'package:statemachine/statemachine.dart'; class GuardedMachine extends Machine { @override GuardedState createState(T identifier) => GuardedState(this, identifier); @override set current(Object? state) { final target = state is...

This library doesn't enforce a specific way to model or pass data. The most strait-forward way would be if you stored the object in a variable that both handlers have...

```dart class Data { String? input; String? output; } void main() { final machine = Machine(); machine.onBeforeTransition.forEach((event) => event.target?.identifier.input = event.source?.identifier.output); final stateA = machine.newState(Data()); final stateB = machine.newState(Data()); stateA.enter();...

That sounds like a useful idea, if the typing doesn't get too messy. I have to think about this a bit more.

`State` where `I` is the type for the identifier (present today), and `C` is the type of the context (or mutable data). - Adding `C` per `State` would make the...