src/part11.rs

   1 // Rust-101, Part 11: Trait Objects, Box (WIP)
   2 // ===========================================
   3
   4 //@ Now that we know about closures, let's have some fun with them. We will try to implement some kind of generic "callback"
   5 //@ mechanism, providing two functions: Registering a new callback, and calling all registered callbacks. There will be two
   6 //@ versions, so to avoid clashes of names, we put them into modules.
   7
   8 mod callbacks {
   9     //@ First of all, we need to find a way to store the callbacks. Clearly, there will be a `Vec` involves, so that we can
  10     //@ always grow the number of registered callbacks. A callback will be a closure, i.e., something implementing
  11     //@ `FnMut(i32)` (we want to call this multiple times, so clearly `FnOnce` would be no good). So our first attempt may be the following.
  12     // For now, we just decide that the callbakcs have an argument of type `i32`.
  13     struct CallbacksV1<F: FnMut(i32)> {
  14         callbacks: Vec<F>,
  15     }
  16     //@ However, this will not work. Remember how the "type" of a closure is specific to the environment of captures variables. Different closures
  17     //@ all implementing `FnMut(i32)` may be different types. However, a `Vec<F>` is a *uniformly typed* vector.
  18
  19     //@ We will this need a way to store things of *different* types in the same vector. We know all these types implement `FnMut(i32)`. For this scenario,
  20     //@ Rust provides *trait objects*: The truth is, that `FnMut(i32)` is not just a trait. It is also a type, that can be given to anything implementing
  21     //@ this trait. So, we may write:
  22     /* struct CallbacksV2 {
  23         callbacks: Vec<FnMut(i32)>,
  24     } */
  25     //@ But, Rust complains about this definition. It says something about "Sized". What's the trouble? See, for many things we want to do, it is crucial that
  26     //@ Rust knows the precise, fixed size of the type - that is, how large will this type be when represented in memory. For example, for a `Vec`, the
  27     //@ elements are stored one right after the other. How should that be possible, without a fixed size? The trouble is, `FnMut(i32)` could be of any size.
  28     //@ We don't know how large that "type that implemenets `FnMut(i32)`" is. Rust calls this an *unsized* type. Whenever we introduce a type variable, Rust
  29     //@ will implicitly add a bound to that variable, demanding that it is sized. That's why we did not have to worry about this so far.
  30     //@ You can, btw, opt-out of this implicit bound by saying `T: ?Sized`. Then `T` may or may not be sized.
  31
  32     //@ So, what can we do, if we can't store the callbacks in a vector? We can put them in a box. Semantically, `Box<T>` is a lot like `T`: You fully own
  33     //@ the data stored there. On the machine, however, `Box<T>` is a *pointer* to `T`. It is a lot like `std::unique_ptr` in C++. In our current example,
  34     //@ the important bit is that since it's a pointer, `T` can be unsized, but `Box<T>` itself will always be sized. So we can put it in a `Vec`.
  35     struct Callbacks {
  36         callbacks: Vec<Box<FnMut(i32)>>,
  37     }
  38
  39     impl Callbacks {
  40         // Now we can provide some functions. The constructor should be straight-forward.
  41         fn new() -> Self {
  42             Callbacks { callbacks: Vec::new() }                     /*@*/
  43         }
  44
  45         // Registration simply stores the callback.
  46         fn register(&mut self, callback: Box<FnMut(i32)>) {
  47             self.callbacks.push(callback);                          /*@*/
  48         }
  49
  50         // And here we call all the stored callbacks.
  51         fn call(&mut self, val: i32) {
  52             // Since they are of type `FnMut`, we need to mutably iterate. Notice that boxes dereference implicitly.
  53             for callback in self.callbacks.iter_mut() {
  54                 callback(val);                                      /*@*/
  55             }
  56         }
  57     }
  58
  59     // Now we are read for the demo.
  60     pub fn demo() {
  61         let mut c = Callbacks::new();
  62         c.register(Box::new(|val| println!("Callback 1: {}", val)));
  63
  64         c.call(0);
  65
  66         //@ We can even register callbacks that modify their environment. Rust will again attempt to borrow `count`. However,
  67         //@ that doesn't work out this time: Since we want to put this thing in a `Box`, it could live longer than the function
  68         //@ we are in. Then the borrow of `count` would become invalid. However, we can tell rust to `move` ownership of the
  69         //@ variable into the closure. Its environment will then contain an `usize` rather than a `&mut uszie`, and have
  70         //@ no effect on this local variable anymore.
  71         let mut count: usize = 0;
  72         c.register(Box::new(move |val| { count = count+1; println!("Callback 2, {}. time: {}", count, val); } ));
  73         c.call(1);
  74         c.call(2);
  75     }
  76
  77 }
  78
  79 // Remember to edit `main.rs` to run the demo.
  80 pub fn main() {
  81     callbacks::demo();
  82 }
  83
  84 mod callbacks_clone {
  85     //@ So, this worked great, didn't it! There's one point though that I'd like to emphasize: One cannot `clone` a closure.
  86     //@ Hence it becomes impossibly to implement `Clone` for our `Callbacks` type. What could we do about this?
  87
  88     //@ You already learned about `Box` above. `Box` is historically a very special type in Rust (though it lost most of its
  89     //@ particularities by now, and people are working on making it just a normal library type). Effectively, however, it is
  90     //@ just an example of a *smart pointer*: It's like a pointer (i.e., a borrow), but with some additional smarts to it. For
  91     //@ `Box`, that's the part about ownership. Once you drop the box, the content it points to will also be deleted.
  92     //@
  93     //@ Another example of a smart pointer in Rust is `Rc<T>`. This is short for *reference-counter*, so you can already guess how
  94     //@ this pointer is smart: It has a reference count. You can `clone` an `Rc` as often as you want, that doesn't affect the
  95     //@ data it contains at all. It only creates more references to the same data. Once all the references are gone, the data is
  96     //@ deleted.
  97     //@
  98     //@ Wait a moment, you may here. Multiple references to the same data? That's aliasing! Indeed, we have to be careful here.
  99     //@ Once data is stored in an `Rc`, is is read-only: By dereferencing the smart `Rc`, you can only get a shared borrow of the data.
 100     use std::rc;
 101
 102     //@ Because of this read-only restriction, we cannot use `FnMut` here: We'd be unable to call the function with a mutable borrow
 103     //@ of it's environment! So we have to go with `Fn`. We wrap that in an `Rc`, and then Rust happily derives `Clone` for us.
 104     #[derive(Clone)]
 105     struct Callbacks {
 106         callbacks: Vec<rc::Rc<Fn(i32)>>,
 107     }
 108
 109     // The methods on these clonable callbacks are just like the ones above.
 110     impl Callbacks {
 111         fn new() -> Self {
 112             Callbacks { callbacks: Vec::new() }                     /*@*/
 113         }
 114
 115         fn register(&mut self, callback: rc::Rc<Fn(i32)>) {
 116             self.callbacks.push(callback);                          /*@*/
 117         }
 118
 119         fn call(&mut self, val: i32) {
 120             // We only need a shared iterator here. `Rc` also implicitly dereferences, so we can just call the callback.
 121             for callback in self.callbacks.iter() {
 122                 callback(val);                                      /*@*/
 123             }
 124         }
 125     }
 126
 127     // The demo works just as above. Our counting callback doesn't work anymore though, because we are using `Fn` now.
 128     fn demo() {
 129         let mut c = Callbacks::new();
 130         c.register(rc::Rc::new(|val| println!("Callback 1: {}", val)));
 131
 132         c.call(0);
 133         c.call(1);
 134     }
 135 }
 136
 137 // **Exercise 11.1**: We made the arbitrary choice of using `i32` for the arguments. Generalize the data-structures above
 138 // to work with an arbitrary type `T` that's passed to the callbacks. Since you need to call multiple callbacks with the
 139 // same `t: T`, you will either have to restrict `T` to `Copy` types, or pass a borrow.
 140
 141 //@ [index](main.html) | [previous](part10.html) | [next](main.html)