Ruby on MEF: Hybrid Application

Since the last installment in this little series, I've started to consider how Ruby/C# hybrid MEF applications might look.

The result is yet another component-based calculator:

Besides the Radiohead arithmetic, there is one reason to get excited...

Ruby parts! (I bet you hadn't guessed.)

The Ruby-based export and import features are heading towards a fairly natural syntax. IOperation, for example, is a regular .NET interface type:

Let's take a look at how the Ruby implementation is woven into the app.

Configuration

This is still a work-in-progress, so configuration is basic. All of the Ruby parts are loaded from a single file that is fed into the RubyCatalog:

The calculator_ops.rb file contains part definitions like Multiply from above.

An additional catalog adds all of the C# parts to the composition as well:

Main Window

The main window is a typical WPF Window that Imports a list of operations:

Because the MainWindow is instantiated and composed by MEF, all known exporters of IOperation will be provided, regardless of the language they're implemented in.

Bi-Directional Composition

You'll notice that the MainWindow class implements the IErrorLog contract. This allows messages from the parts to be presented to the user:

Parts that wish to access the IErrorLog service from Ruby can import it:

The integration (and IronRuby in general) treats interface contracts as Ruby Module objects, so the IErrorLog used by the Divide part could be implemented by a Ruby object, although I haven't tested that case.

Fanatics take note: I did attempt to use IronRuby's case-transforming features to allow Symbol and Apply() to be specified in their natural Ruby forms (symbol and apply() ) but had no success. Hopefully I'll resolve this in a future version.

Monkeypatching the Export Type

I can't say whether this will turn out to be a good move or not, but right now it seems reasonable.

Notice this method call:

In order to support MEF's lazy-instantiation feature, the @error_log attribute needs to be of type System::ComponentModel::Composition::Export, which will supply the actual instance when it is required through the get_exported_object() method. Calling @error_log.get_exported_object.add_message felt decidedly unnatural, so I've added method forwarding to the Ruby version of the Export class:

I've had to do some type aliasing to disambiguate Export from Export<T> , but otherwise this is straightforward. Rubyists, please weigh in and let me know if this implementation is less-than-desirable :)

Source Code

Once again you can download the full source code for this article from SkyDrive.