reem / rust-plugin

Type-Safe, Lazily Evaluated, Plugins for Extensible Types

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 typemap::Key for IntPlugin { type Value = i32; }

// Define the plugin evaluation function.
// `Extended` is a type that implements `Extensible`.
impl Plugin<Extended> for IntPlugin {
    type Error = ();

    fn eval(_: &mut Extended) -> Result<i32, ()> {
        Ok(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>();

rust-plugin's Issues

Support for Configured Plugins

Right now, using plugins that require any kind of configuration requires pretty significant shenanigans. This should change.

Add LICENSE file

Please include full LICENSE text and release new version. Thanks!

rust-plugin fails to build with nightly

Getting a build failure using rust nightly as part of Iron's dependencies during a cargo build

rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +0000)

   Compiling plugin v0.0.0 (https://github.com/reem/rust-plugin.git#3f2a70b1)
Could not compile `plugin`.

--- stderr
src/lib.rs:116:1: 116:52 error: the parameter type `R` may not live long enough; consider adding an explicit lifetime bound `R:'static`...
src/lib.rs:116 impl<E: Extensible, R: Clone> GetCached<R> for E {}
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/lib.rs:116:1: 116:52 note: ...so that the parameter `R`, when instantiated with `R`, will meet its declared lifetime bounds.
src/lib.rs:116 impl<E: Extensible, R: Clone> GetCached<R> for E {}
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

Build on only stable rust

Needed unstable APIs:

• std::intrinsics::unreachable

cc iron/iron#317

Support using SendMap for Extensible

Hi all,

I'm trying to get Iron ported over to Hyper's master branch, which is based on tokio (PR iron/iron#523). My current attempt requires that the Iron::Response type is Send. However, because Response contains a TypeMap, the compiler won't typecheck. I tried changing it to a SendMap, which then failed as Response implements Extensible from this crate which only supports TypeMap.

I tried generalizing Extensible (and thus the methods of Pluggable) over the trait passed to TypeMap, however the compiler was then unhappy as I couldn't convince it that Plugin::Value implemented typemap::internals::Implements as I can't directly specify that restriction due to typemap::internals being private. I tried making a shadow of typemap::internals::Implements, but it seems the compiler isn't smart enough to realize my shadow meant Implements had to be implemented.

I'm not sure how to proceed at this point. Do you have any suggestions? Would exposing Implements from typemap be ok?

Access to plugin instance and other improvements

Hello @reem.

1. I have looked at the latest changes and I have several comments. At first, (0d1311b#commitcomment-9673644) I think we still need an access to the plugin instance to make plugins configurable.
2. The second thought is about the (1207586#commitcomment-9673674) plugin return type. I think that we still need Option<Self::Value> for cases when there is no value and no error. So I suggest Result<Option<Self::Value>, Self::Error>. What do you think?