CODEWITHSUNDEEP
rust
alexa griffin
alexa griffin

Reputation: 115

Storing a module as a variable in rust

I have 2 different modules with precisely the same implementation, same functions, types, etc. They just do different things. I would like to be able to choose one of these modules at runtime and use it exclusively. Furthermore, there are several of these modules that may or may not exist at compile-time based on platform, features, etc. this is a link to a super stripped-down version of what I want. I am trying to choose between the various gfx-hal backends. The best I have been able to come up with is a macro that creates an if statement for each possible module then fires that if statement whenever a function in a module is run. However, this doesn't really seem elegant or at all good. So is there a way to store the modules in a variable and access it, or some way to do this that mimics that?

Thanks in advance

Upvotes: 4

Views: 945

Answers (1)

Optimistic Peach
Optimistic Peach

Reputation: 4288

You could do this by turning each of your modules into its own trait implementation, similar to how gfx-rs does things.

Your "trait" would in actuality never be implemented with state, and instead be a collection of associated items like functions, other types, etc.

You could package it up like so:

#![allow(dead_code)]
mod foo {
    pub fn print() { println!("hello from foo") }
}

mod bar {
    pub fn print() { println!("hello from bar"); }
}

mod zam { // this may not exist depending on the platform, one will always exist
    pub fn print() { println!("hello from zam"); }
}

struct FOO;
struct BAR;
struct ZAM;

trait RuntimeModule {
    fn print();
}

impl RuntimeModule for FOO {
    fn print() { foo::print(); }
}

impl RuntimeModule for BAR {
    fn print() { bar::print(); }
}

impl RuntimeModule for ZAM {
    fn print() { zam::print(); }
}

fn main() {
    // Here we decide which to use
    print_module::<FOO>();
}
// This is our "entrypoint"
fn print_module<T: RuntimeModule>() {
    T::print();
}

If we decide which to use at runtime (in this case in main), we can then call a generic function which will use the associated types/functions to make decisions.

Note that you would not be able to use Box<dyn RuntimeModule> if RuntimeModule contained associated types that were different for each implementation.

Upvotes: 3

Related Questions