Niko Matsakis wrote:
Basically what I'm getting at here is that both *freezable* and
*persistent* maps share the property that they *act like immutable
values*. This is true *even though* freezable maps are modified
in-place, because *at the time of modification* no aliases exist, so
who's to say you didn't swap in a new map?
Taking this idea a little further, you could almost just have one interface:
trait Map<K,V> {
fn add(&mut self, k: K, v: V);
fn remove(&mut self, k: &K);
fn plus(&self, k: K, v: V) -> self;
fn minus(&self, k: &K) -> self;
}
In the case of a persistent map, `add()` and `remove()` are impl'd in
terms of `plus()` and `minus()`, but for an in-place, freezable
map---which I will call an imperative map---it's the other way around:
trait ImperativeMap<K,V> : Map<K,V> {
fn add(&mut self, k: K, v: V);
fn remove(&mut self, k: &K);
fn plus(&self, k: K, v: V) -> self {
let mut m = *self; // Problem: requires that K and V be
copyable.
m.add(k, v);
return m;
}
fn minus(&self, k: &K) -> self { ... }
}
As I wrote this, though, I realize the flaw: K and V would have to be
declared copyable, which we do not want to require.
Niko
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
