More flexible alternative to BufferContainer

[DavJCosby]

This hit me in the shower today.

What if instead of this:

#[startup_commands]
fn startup(buffers: &mut BufferContainer) -> SledResult {
    let colors: &mut Vec<Rgb>  = buffers.create_buffer::<Rgb>("colors");
    colors.extend([
        Rgb::new(1.0, 0.0, 0.0),
        Rgb::new(0.0, 0.0, 1.0),
        Rgb::new(0.0, 1.0, 0.0),
    ]);
    Ok(())
}

we had something like this?

#[startup_commands]
fn startup(data: &mut DriverData) -> SledResult {
    data.set::<Vec<Rgb>>("colors", vec![
        Rgb::new(1.0, 0.0, 0.0),
        Rgb::new(0.0, 0.0, 1.0),
        Rgb::new(0.0, 1.0, 0.0),
    ]);
    //-- snip --
    Ok(())
}

(most type annotations are unnecessary and are only included for clarity)

Why?

Users don't always need to store a whole bunch of values at once. And sometimes when they do, they know how many values they'd like to store and would prefer to use a fixed-size array. This design lets you choose exactly how you'd like to store your data.

Filters would probably get dissolved by this too.
Instead of doing:

#[startup_commands]
fn startup(sled: &mut Sled, filters: &mut Filters) -> SledResult {
    let area: Filter = sled.within_dist_from(5.0, Vec2::new(-0.25, 1.5));
    filters.set("area_of_effect", area);
    //-- snip --
    Ok(())
}

You would do:

#[startup_commands]
fn startup(sled: &mut Sled, data: &mut DriverData) -> SledResult {
    let area: Filter = sled.within_dist_from(5.0, Vec2::new(-0.25, 1.5));
    data.set("area_of_effect", area);
    //-- snip --
    Ok(())
}

Methods

data.store::<T>(key: &str, value: T) -> &mut T;
data.set::<T>(key: &str, value: T);
data.get::<T>(key: &str) -> SledResult<&T>;
data.get_mut::<T>(key: &str) -> SledResult<&mut T>;
data.exists::<T>(key: &str) -> bool;
data.empty_at(key: &str) -> bool;

[DavJCosby]

Beginning work on the BufferContainerOverhaul branch.