What if the state's fields are private, and in a different module than the players, but exposes getters to query the state? Then the players can't modify it, but if the component that processes the actions has visibility into the state's fields, it can modify them just fine.
-Kevin On Feb 14, 2014, at 12:22 PM, Damien Radtke <damienrad...@gmail.com> wrote: > I'm trying to write what is essentially a card game simulator in Rust, but > I'm running into a bit of a roadblock with Rust's memory management. The gist > of what I want to accomplish is: > > 1. In the program's main loop, iterate over several "players" and call their > "play" method in turn. > 2. Each "play" method should be able to send requests back to the parent in > order to take certain actions, who will validate that the action is possible > and update the player's state accordingly. > > The problem I'm running into is that, in order to let a player "play" and > have the game validate actions for them, I would need to run each player in > their own task, (I considered implementing it as each function call > indicating a request for action [e.g. by returning Some(action), or None when > finished] and calling it repeatedly until none are taken, but this makes the > implementation for each player needlessly complex) but this makes for some > tricky situations. > > My current implementation uses a DuplexStream to communicate back and forth, > the child sending requests to the parent and the parent sending responses, > but then I run into the issue of how to inform the child of their current > state, but don't let them modify it outside of sending action requests. > > Ideally I'd like to be able to create an (unsafe) immutable pointer to the > state held by the parent as mutable, but that gives me a "values differ in > mutability" error. Other approaches so far have failed as well; Arcs don't > work because I need to have one-sided mutability; standard borrowed pointers > don't work because the child and parent need to access it at the same time > (though only the parent should be able to modify it, ensuring its safety); > even copying the state doesn't work because the child then needs to update > its local state with a new copy sent by the parent, which is also prone to > mutability-related errors. > > Any tips on how to accomplish something like this? > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
