Command pattern in Rust - rust

Question

I'm trying to implement a command line server application in Rust.
I'd like to have a list (or hash table) of commands that I can iterate over for printing usage and looking up/executing commands.
My problem is that each Command needs mutable references to the thing the command uses to execute (such as inserting a user into a database or something). The borrow checker obviously doesn't like passing multiple mutable references around. Is there a way to do this? I started by having the execute method take in a reference to the things it needed but then I need a separate list for commands that need different things which sounds like it would get unwieldy.
Here's an example of the problem:
struct SomeStruct {
pub some_field: String,
}
impl SomeStruct {
pub fn new(field: String) -> SomeStruct {
let some_struct = SomeStruct {
some_field: field,
};
return some_struct;
}
pub fn change_field(&mut self) {
self.some_field = "Something else".to_string();
}
}
struct SomeCommand<'a> {
pub some_struct: &'a mut SomeStruct,
}
impl<'a> SomeCommand<'a> {
pub fn new(the_struct: &'a mut SomeStruct) -> SomeCommand {
let some_command = SomeCommand {
some_struct: the_struct,
};
return some_command;
}
pub fn execute(&mut self) {
self.some_struct.change_field();
}
}
fn main() {
let mut some_struct = SomeStruct::new("hey".to_string());
let some_command1 = SomeCommand::new(&mut some_struct);
// Compiler complains because I'm making another mutable binding to some_struct
let some_command2 = SomeCommand::new(&mut some_struct);
}
Is there a better way to do this?

Answer 1

I was trying to do the same in Rust, following examples in book Design Patterns. The problem here is that we need to maintain the generic interface of the Command trait, which means we should not design the trait such that it takes specific objects of certain types. The only solution we are left with is to store a mutable reference to the object itself within the concrete instance of object that implements Command trait. However, if we use &'a mut ..., Rust compiler will not like multiple mutable references to a single object, which means we can only ever have one Command instance for any given object we want to execute the command on, and we can only call execute once.
This can be achieved by using RefCell or Arc<Mutex<>>. I have implemented both and they both work very well. The difference is that RefCell is not thread-safe, so you cannot share the same Command object across threads if you choose to implement it in this way; whereas Arc<Mutex<>> is thread-safe.
Below is my implementation:
trait Command {
fn execute(&mut self); // Execute command.
fn is_reversible(&self) -> bool; // Undoable operation?
fn unexecute(&mut self); // Undo command.
}
// ------ Using RefCell ------
struct ChangeFontSizeCommand<'a> {
text: &'a RefCell<dyn Text>,
old_size: Option<usize>,
new_size: usize
}
impl<'a> Command for ChangeFontSizeCommand<'a> {
// Implementation... (many calls to .borrow() and .borrow_mut())
}
impl<'a> ChangeFontSizeCommand<'a> {
pub fn new(text: &'a RefCell<dyn Text>, new_size: usize) -> Self {
// Implementation...
}
}
// ------ Using Arc and Mutex ------
struct ChangeFontColorCommand {
text: Arc<Mutex<dyn Text>>,
old_color: Option<Color>,
new_color: Color
}
impl Command for ChangeFontColorCommand {
// Implementation... (many calls to .lock().unwrap())
}
impl ChangeFontColorCommand {
pub fn new(text: Arc<Mutex<dyn Text>>, new_color: Color) -> Self {
// Implementation...
}
}
Notice that in both examples, instance of RefCell or Arc<Mutex<>> has to be created outside of object initializer, we cannot pass in a mutable reference and create them inside of the command implementation struct, that would violate Rust's borrow checker rules.

Answer 2

I think passing the mutable reference as a parameter of execute() instead of storing it within SomeCommand is the way to go. Don't keep references living longer than they need to live.
But this is a fairly broad question: I can think of a dozen possible solutions -- it's hard to tell what's best in your case, since your example is pretty generic. Maybe we could be more specific after you told us a little more (maybe a small subset of features you want to implement).
Just looking at the title of your post: docopt is used by many Rust project -- AFAIK even cargo uses it. However, I suspect it doesn't help you with your main design problem.
Besides: in your new methods you can delete some code thanks to implicit returns. This:
pub fn new(field: String) -> SomeStruct {
let some_struct = SomeStruct {
some_field: field,
};
return some_struct;
}
... becomes this:
pub fn new(field: String) -> SomeStruct {
SomeStruct {
some_field: field,
}
}