You could store the matches in a HashMap
as well, using some MatchId
type as the key, i.e., HashMap<MatchId, Match>
. Then you can use that as the reference in players: HashMap<String, MatchID>
. Only downside is that you have to generate unique MatchId
s, e.g., by using some counter.
Rust
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
This is exactly the use case that slotmap is meant for. I highly recommend using the library rather than reinventing the concept.
Ah, that does seem like it will solve the problem. Thanks!
Could you not have a hashmap keyed on matches pointing to vectors of strings for the players in each match? Basically modeling the data how you want rather than relying on indexing.
Not sure I understand. What I'm trying to do is something like this:
- Poll a stream which takes fedi events. Read player commands.
- If an event comes from a known player, check which match they are into.
- With that info, get their opponents/coplayers etc and perform the change of state in the game (send replies, next turn, etc).
So what I have as a key is a player name (AP username) and from that I need to find which match they're in.
There's nothing semantically useful about a match ID.
If you instead made your lobby
field a HashMap<String, MatchId>
, then whenever you get an event from a known player, you can lookup the match they are in from the lobby map and use that to lookup other data about the match (such as the other players) via the matches
field (assuming that was also changed to be a hashmap as described in my previous comment).
I don't think there is a good way of having references within the same struct, but you could store reference counted matches:
matches: Vec<Rc<Match>>,
players: HashMap<String, Rc<Match>>,
You would still have to make sure that the players
map is updated, maybe weak references are useful there.
Maybe you could also consider storing the players of a match in the match itself, not outside.
Thanks, the RC is a possible approach. It seems to violate DRY a bit but maybe there's no way around it.
The reason I had the players outside the match is that I need them there anyway, because when I get a player action I need to check in which match they are, who are their opponent(s) and so on. So even if they're in, they'll have to be out too as there are concurrent matches and the player actions come all through the same network stream.