I'm writing a hardware access library: #libobscura .
A new idea just popped into my mind: use a special structure for anything that does I/O.
struct Io;
impl Io {
fn device_exists(&self) -> io::Result;
...
}
I'm thinking if I had an Io trait, I could abstract it and use a #mock for #testing.
Is anyone else doing it? Is it a good idea?
[#]drivers #Rust #rustlang #AskFedi
=> More informations about this toot | More toots from dcz@fosstodon.org
@dcz perhaps can borrow ideas from this project
https://docs.rust-embedded.org
=> More informations about this toot | More toots from Workshopshed@mastodon.scot
@dcz
In my day job with Go, this is basically what I do.
I also try to separate io from processing.
So there's some glue code between io and logic. That glue can be validated like that, with a mocked IO. Or I trust it is simple enough. (Not the best strategy, but often good enough)
That glue calls out to logic which then is relatively easy to test because it is mostly pure functions.
=> More informations about this toot | More toots from tschundler@leds.social
@dcz
Interfaces and dependency injection are I think not used and appreciated enough! Definitely do it. And see also https://www.firezone.dev/blog/sans-io
=> More informations about this toot | More toots from etam@im-in.space
@etam I looked at sans-io, but I think building the state machine explicitly sacrifices too much: what would have been expressed as consecutive lines now has complex control flow. I'd actually rather choose async.
In the case of dependency injection of IO described by an interface, I tried it somewhere else and the amount of abstraction created a huge mess, so I wonder what other people's experiences are.
=> More informations about this toot | More toots from dcz@fosstodon.org This content has been proxied by September (3851b).Proxy Information
text/gemini