Summary
ChartAIController and GridAIController expose state-change notifications via:
public Registration addStateChangeListener(SerializableConsumer<ChartState> listener)
public Registration addStateChangeListener(SerializableConsumer<GridState> listener)
The addListener shape doesn't quite fit how this hook is used in practice and is worth reconsidering before the API stabilizes.
addListener semantics for what is essentially a single persistence hook
The documented use case is persistence: hook in once, save the state when the controller fires. In practice there's only ever one consumer per controller. The "add many" semantics carry costs without obvious payoff:
- Encourages users to think about ordering, idempotency, and removal that aren't real concerns for a single persistence callback.
- Implementation maintains a list and registration tokens that wouldn't be needed for a single handler.
A setStateHandler(...) style API (one handler, replaceable, no Registration) would more directly match the intent.
Proposal
Discuss whether to evolve the API to something like:
public void setStateHandler(SerializableConsumer<ChartState> handler);
before the controllers' API is locked in.
Summary
ChartAIControllerandGridAIControllerexpose state-change notifications via:The
addListenershape doesn't quite fit how this hook is used in practice and is worth reconsidering before the API stabilizes.addListenersemantics for what is essentially a single persistence hookThe documented use case is persistence: hook in once, save the state when the controller fires. In practice there's only ever one consumer per controller. The "add many" semantics carry costs without obvious payoff:
A
setStateHandler(...)style API (one handler, replaceable, noRegistration) would more directly match the intent.Proposal
Discuss whether to evolve the API to something like:
before the controllers' API is locked in.