opentofu/internal/refactoring
Martin Atkins dc5964f8a3 refactoring: Use addrs.Map for maps with addresses as keys
We introduced the addrs.UniqueKey and addrs.UniqueKeyer mechanics as part
of implementing the ValidateMoves and ApplyMoves functions, as a way to
better encapsulate the solution to the problem that lots of our address
types aren't comparable and so cannot be used directly as map keys.

However, exposing addrs.UniqueKey handling directly in the logic adds
various noise to the algorithms and, in particular, obscures the fact that
MoveResults.Changes and MoveResult.Blocked both have different map key
types.

Here then we'll use the new addrs.Map helper type, which encapsulates the
idea of a map from an addrs.UniqueKeyer type to an arbitrary value type,
using the unique keys as the map keys internally. This does unfortunately
mean that we lose the conventional Go map access syntax and have to use
a method-based API instead, but I (subjectively) think that's an okay
compromise in return for avoiding the need to keep track inline of which
addrs.UniqueKey values correspond with which real addresses.

This is intended as an entirely-mechanical change, with equivalent
behavior to what it replaced. If anything here is doing something
materially different than what it replaced then that's a mistake.
2022-06-16 07:03:36 -07:00
..
testdata find implied moves in nested modules 2022-01-04 09:20:47 -05:00
move_execute_test.go refactoring: Use addrs.Map for maps with addresses as keys 2022-06-16 07:03:36 -07:00
move_execute.go refactoring: Use addrs.Map for maps with addresses as keys 2022-06-16 07:03:36 -07:00
move_statement_test.go find implied moves in nested modules 2022-01-04 09:20:47 -05:00
move_statement.go find implied moves in nested modules 2022-01-04 09:20:47 -05:00
move_validate_test.go refactoring: Implied move statements can be cross-package 2022-01-11 08:43:57 -08:00
move_validate.go refactoring: Use addrs.Map for maps with addresses as keys 2022-06-16 07:03:36 -07:00