Wrap environments in RefCell

[kinrezC]

Currently in order to add environments to the manager one must carry a mutable reference to the manager. Using RefCell allows you to track an immutable reference to the manager while allowing for interior mutability on the environments.

[Autoparallel]

Does it matter if we carry around a mutable reference to manager?

[Autoparallel]

If we do want to remove &mut self on the methods, can we maybe make a method for the manager that is something like:

pub fn get_environment<S: Into<String>>(&self, label: S) -> Option<&Environment> {
    self.environments.borrow().get(label)
}

[kinrezC]

Does it matter if we carry around a mutable reference to manager?

I figure there may be cases where you want to carry many references to the manager at one time (e.g. you want to create several environments with different configurations?). It wouldn't be possible to satisfy rust borrow rules in this scenario.

[0xJepsen]

Does it matter if we carry around a mutable reference to manager?

I figure there may be cases where you want to carry many references to the manager at one time (e.g. you want to create several environments with different configurations?). It wouldn't be possible to satisfy rust borrow rules in this scenario.

I think this is a good change and am for merging this

[0xJepsen]

lgtm

[Autoparallel]

I figure there may be cases where you want to carry many references to the manager at one time (e.g. you want to create several environments with different configurations?). It wouldn't be possible to satisfy rust borrow rules in this scenario.

I don't think I follow. With the current set up, I can create multiple environments with different configs and I don't run into any borrow rules.

I can just

let mut manager = Manager::new();
manager.add_environment("label",..);
manager.add_environment("label_2",..);
// ~ etc.

It would only matter if we have a function like so:

fn do_something(mut manager: Manager) ..

[0xJepsen]

Maybe we close this for now? Thoughts @kinrezC and @Autoparallel?

[Autoparallel]

Maybe we close this for now? Thoughts @kinrezC and @Autoparallel?

That's my preference. I think we should revisit something like this if we run into an issue down the road in making simulations.