You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason we only support immutable state is that it is stored as snapshot asynchronously.
For Java it's cumbersome to be strictly immutable, and less familiar.
The builders for event and command dispatch work fine when defined outside the State, but if we want to support a ADT style where the actual logic of how to apply the events is defined in the concrete State classes. Due to lack of pattern matching in Java we would have to use builders for matching on the events, but creating a new builder for each invocation seems very wasteful and contradicts the idea that a builder is created once to construct the function, which is then invoked many times.
By allowing mutable State classes the builder can be used inside the state class.
Two solutions were suggested:
don't process any new commands while snapshotting is in progress (like for events), possibility to opt-out if state is immutable
The reason we only support immutable state is that it is stored as snapshot asynchronously.
For Java it's cumbersome to be strictly immutable, and less familiar.
The builders for event and command dispatch work fine when defined outside the State, but if we want to support a ADT style where the actual logic of how to apply the events is defined in the concrete State classes. Due to lack of pattern matching in Java we would have to use builders for matching on the events, but creating a new builder for each invocation seems very wasteful and contradicts the idea that a builder is created once to construct the function, which is then invoked many times.
By allowing mutable State classes the builder can be used inside the state class.
Two solutions were suggested:
Some experiments in #25729
The text was updated successfully, but these errors were encountered: