11 releases

Uses old Rust 2015

0.2.6 Apr 22, 2015
0.2.5 Apr 3, 2015
0.2.4 Mar 31, 2015
0.2.2 Feb 28, 2015
0.0.0 Nov 11, 2014

#1631 in Rust patterns

Download history 2075/week @ 2023-08-11 2142/week @ 2023-08-18 2434/week @ 2023-08-25 1913/week @ 2023-09-01 2380/week @ 2023-09-08 2266/week @ 2023-09-15 1710/week @ 2023-09-22 2145/week @ 2023-09-29 2413/week @ 2023-10-06 2576/week @ 2023-10-13 2570/week @ 2023-10-20 2926/week @ 2023-10-27 3134/week @ 2023-11-03 2066/week @ 2023-11-10 2493/week @ 2023-11-17 2209/week @ 2023-11-24

10,528 downloads per month
Used in 188 crates (19 directly)

MIT license

8KB
113 lines

Plugin

Type-Safe, Lazily Evaluated, Plugins for Extensible Types

Plugins provide a consistent interface for mixin methods. You can use a plugin anywhere you would use a "mixin" trait and an implementation.

Example Usage

// Define a struct.
struct IntPlugin;

// Map it onto an `i32` value.
impl Assoc<i32> for IntPlugin {}

// Define the plugin evaluation function.
// `Extended` is a type that implements `Extensible`.
impl PluginFor<Extended, i32> for IntPlugin {
    fn eval(_: &Extended, _: Phantom<IntPlugin>) -> Option<i32> {
        Some(0i32)
    }
}
assert_eq!(extended.get::<IntPlugin>().unwrap(), 0i32);

To do the same thing with a trait, one could do:

trait IntProducer {
    fn get_int_value(&self) -> Option<i32>;
}

impl IntProducer for Extended {
    fn get_int_value(&self) -> Option<i32> {
        Some(0i32)
    }
}

Although using a raw trait is less code, plugins provide the following advantages:

  • Automatic caching of values. Calling a method again is a constant time operation! This is particularly useful in pipeline structures where only the extensible object is passed around.
  • A consistent interface, which also allows for neater name clash resolution. Two modules that provide PluginX can be differentiated using a module prefix.
e.get::<mod1::PluginX>();
e.get::<mod2::PluginX>();

Dependencies

~29KB