MSDN Magazine - February 2009 - (Page 60)

I created a Hello4Times class that inherits from Hello3Times, which inherits from the interface but has implemented three extra HelloWorld methods. Within the class I define a new method called HelloMethodOn4Times that calls the base implementation: Once the DLR has the AST, it converts the tree into Intermediate Language (IL). All .NET code is compiled down into IL to provide a generic language for the CLR. This is how IronRuby can interoperate with the .NET Framework—behind the scenes, all the code is executed as IL instrucpublic class Hello4Times : Hello3Times { tions. After the DLR has completed the converpublic string HelloMethodOn4Times () { Figure 2 Displaying a Custom sion, it passes the IL to the CLR for execution return base.HelloWorld(); MessageBox from Ruby } and the result is returned to IronRuby. } During this process there are additional steps to improve perforI then defined a static class and methods that will return a new mance and reliability, such as caching. For a deeper explanation, I instance of the Hello4Times class but return it to the calling code as recommend reading Bill Chiles’s CLR Inside Out column “Ironan interface. This means the calling code should only know about Python and the Dynamic Language Runtime” in the October 2007 HelloWorld, not any of the additional methods defined: issue of MSDN Magazine (msdn.microsoft.com/magazine/cc163344). public static class HelloWorld { Within a separate assembly there is a hosting API that allows you public static IHello ReturnHello4TimesAsInterface() { return new Hello4Times(); to embed IronRuby within your own applications, allowing you to } execute Ruby code from C# or users to execute their own code. For more about the IronRuby implementation, download the In my Ruby code, I have two method calls. The first call is on the interface-defined method, which you would expect to work with- entire source code from RubyForge (rubyforge.org/projects/ironruby). out a problem. However, the second call is to the method on the IronRuby is an open-source project implemented in C# and is an concrete class. IronRuby has determined the type of the object be- excellent example of a dynamic language implementation. IronPython is available as an open source project hosted at CodePlex ing returned and can dispatch the method calls: (codeplex.com/IronPython), and it includes a sample language called Toyputs InteropSample::HelloWorld.ReturnHello4TimesAsInterface.HelloWorld puts interopSample::HelloWorld.ReturnHello4TimesAsInterface. Script if you want an introduction into how the DLR works. HelloMethodOn4Times To ensure continued compatibility with the core Ruby platform, All of this happens without you ever needing to worry about castthe IronRuby team is using RubySpecs. This is a shared set of examing the object to the correct type to call the method. Following this theme, you can extend .NET objects in exactly ples based around how the Ruby language should be implemented. the same fashion as you can with Ruby objects. When displaying The aim of RubySpecs is to ensure different implementations ina MessageBox, I don’t want to keep defining which icons and but- cluding Matz’s Ruby Interpreter (MRI), JRuby, MacRuby, and IronRuby have the same behavior. RubySpecs uses a syntax-compatible tons to use. Instead, I just want to provide a message. Maybe you don’t like the built-in functionality and want to extend version of RSpec called MSpec. These are viewed as the acceptance the actual MessageBox class for seamless interaction. With Ruby, tests for the IronRuby implementation. this is simple. You define a new class that is the same as the built in MessageBox within WPF. You then create a new method on the class that simply calls the show method with various defaults: class System::Windows::MessageBox def self.ShowMessage(msg) System::Windows::MessageBox.Show(msg, msg, \ System::Windows::MessageBoxButton.OK, \ System::Windows::MessageBoxImage.Stop) end end Testing a C# App with IronRuby After executing this block of code System::Windows::MessageBox.ShowMessage( \ "I'm going to show you a message") you can call the ShowMessage method, the result being the message box shown in Figure 2. Inside IronRuby How is interop possible? The answer is the DLR. At a high level, when you execute Ruby code using IronRuby, a lot of work takes place behind the scenes. First, the code you write is tokenized and parsed by the IronRuby engine. The parsed code is then converted into the DLR’s Abstract Syntax Tree (AST). This is a standardized AST that all language implementations, such as IronPython, need to provide to the DLR in order to execute the code. 60 msdn magazine For many years now, the awareness and practice of TDD has increased as a way to develop software, resulting in higher quality code, in terms of design and maintainability, along with fewer defects along the way. With IronRuby, I can use the RSpec specification framework and runner to provide examples of how my C# objects work, following a BDD approach instead of TDD. While the scenario framework, which I’ll cover in a future article, is more aligned with acceptance testing at the app level, the specification framework is more aligned to developers writing their own specifications about the code they are just about to implement and its expected behavior. The specification framework is based around providing examples describing the behavior at the object level. These examples can be run to verify that the implementation of the system is still working as the developer expects while providing documentation about how the objects are expected to behave. This is an important distinction compared to unit-testing frameworks such as NUnit and MbUnit. Both of those use test attributes to indicate a method is a test for the system. RSpec takes a different approach. RSpec says that each method is an example of how the code is intended to work. While the distinction is subtle, it changes IronRuby and RSpec http://msdn.microsoft.com/magazine/cc163344 http://www.rubyforge.org/projects/ironruby http://www.codeplex.com/IronPython

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.