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
Refactor how piece constraints are applied. (#1343)
Refactor how piece constraints are applied.
When I added support for constructors, I introduced a little API to let
pieces enforce constraints between their state and the states of other
child pieces. It worked but felt a little bolted on. In particular,
enforcing the constraints during CodeWriter formatting meant we didn't
prune invalid solutions as efficiently as we could.
I'm working on if elements now and I needed a better way to handle
constraints between pieces for that, so I went ahead and refactored the
way this works to be, I think, generally better:
- Enforce constraints between pieces during solution expansion instead
of during formatting. This means that we eagerly discard any solution
(and the whole tree of solutions that could have come from it) if it
doesn't meet the constraints.
- Remove the `_pieces` fields in PieceStateSet. With the previous
optimization to track the next unsolved piece in Solution, that list
wasn't doing much of anything. It's only use (aside from debug output)
was for determining the order that pieces are compared when comparing
two solutions. But we can get that from iterating over the
_pieceStates map since maps in Dart track their key insertion order.
- Update ConstructorPiece to use this new API.
Co-authored-by: Nate Bosch <[email protected]>
0 commit comments