3 ms·
I'm not sure I understand how the design has ended up with a life of its own. Are you saying that a design emerges without the intention of the programmer just
by blub 6y ago
I'm not sure I understand how the design has ended up with a life of its own. Are you saying that a design emerges without the intention of the programmer just by using Rust?
What do you understand by design in this case?
- Waterluvian 6y agoIm not the brightest bulb around but I’ll try. I wanted a design where every subsystem (ppu, apu, serial, controller, etc.) owned a reference to the singular MMU struct. This is how I’d do it in python. Makes referencing mmu easier. Rust said no, you can’t have many mutable references. I looked around and found refcell and such. Ways to have shared mutability as long as I enforced certain lifetimes and other guarantees that I’m not going to cause memory problems by deleting what other systems expect to be there. This was looking complicated and messy. Sure I could do it. But it spoke to me: “this is probably not right”. I ended up with a design where I have a core “step” function that calls each system’s step function, in order, and passes in a mutable reference to MMU to each. Basically it loans out the MMU one at a time. The result is that testing is so much easier because all my systems are stateless and my MMU holds all the state. I just assemble an MMU state the way I want for each test and evaluate how the system mutated it. It also meant that implementing save/restore state was incredibly easy because my entire guest machine state was in one struct and all the systems were stateless so they didn’t need any logic to recover state.