| trait Actor<T> { | |
| pub fn new(inner: T, pool: &Pool) -> Actor<T>; | |
| pub fn sync<U>(&self, msg: FnOnce(&mut T)) -> U; | |
| pub fn async<U>(&self, msg: FnOnce(&mut T)) -> Future<U>; | |
| } | |
| fn example() { | |
| // wake the main thread and create an actor on it | |
| let button = main_pool.sync( | |
| |pool| Actor::new(Button::new(), pool) |
Actors are a surprisingly useful abstraction, they are an alternative model that gives similar benefit as object ordinated (component interchangeably) but also helps address the concurrency issues that crop up with objects. Actors would could be a good solution to alleviating issues that crop up in building a UI framework in Rust.
This document proposes a hypothetical actor framework that I have been thinking about developing for Rust.
I wanted to give a little bit of a discussion on all my thinking about why UI's are a tricky to get right in Rust. I want to try and differentiate this discussion because there are a number of decent UI frameworks that have been bound to Rust. This is great! I do not want to discourage any of their work, they are wonderful members of our community.
What this is about is how it would be possible to write a good UI framework
| cpu | |
| mov $80c0000, $UNKNOWN_CPU_REG_7 | |
| jmp :80c1128 <_main> | |
| enter R-32 | |
| call :80c0530 <_disable_ints> | |
| cpu | |
| and3 $7000, $UNKNOWN_CPU_REG_5 | |
| cpu | |
| and $ffff8fff, $UNKNOWN_CPU_REG_5 | |
| return R0 |
