MSDN Magazine - February 2009 - (Page 59)

cation. This is extremely useful in dynamic languages, especially in unit testing, as it allows you to customize the behavior of objects and methods to your own requirements. In a similar fashion, you can extend the built-in Ruby classes to provide your own functionally, much like the extension methods in C# 3.0. With C#, there are various restrictions about the methods you can create. For example, they have to be static and in a separate class. This all harms readability. With Ruby, you just create a normal method on an existing class. For example, Integer is a class to handle whole numbers. Integer has a series of methods, but it does not have a method to say whether the number is even. To create such a method, you simply create a new class with the same name (Integer) and define the new method. The question mark at the end of the method denotes that a Boolean is returned with the aim of making it easier to read: class Integer def even?() self.abs % 2 == 0 end end puts 2.even? => true puts 1.even? => false Create a button in the same fashion: mainButton = Button.new mainButton.content = 'I'm a WPF button — press me' In both instances I’m using the alias to access the full name of the object. When the button is clicked, I want to display a MessageBox to the user. As you would in C#, you can subscribe to the event and provide a block that is called when the click event is invoked: mainButton.click do |sender, args| System::Windows::MessageBox.Show("Created using IronRuby!") end Finally, set the content of the window to be the button, create a new Application object, and launch the window: win.content = mainButton my_app = Application.new my_app.run win Ruby and the .NET Framework In place of the old debate about whether to use a static or dynamic language, IronRuby lets you use the right language for the Ruby and the CLR job. If it makes more sense to use C#, then you can use C#. If you Here is another example. If you attempt to access AddRange on need a more dynamic approach, you can easily use IronRuby, tak- IEnumerable, in C# the code would look like this: ing advantage of its interoperability with .NET and the dynamic ArrayList list = new ArrayList(); list.AddRange(new [] { 1,2,3,4 }); nature of the Ruby language. I anticipate people using a mixture of different languages and technologies, such as C# for the main However, with Ruby, the accepted convention is for words within application and Ruby for testing. method names to be separated by underscores to improve readThe DLR provides the foundation to enable .NET interop. With ability. Creating a separate library to follow this convention would this in place, you can take advantage of UI techbe too time-consuming and error-prone, and nology such as Windows Forms, Windows Preit would not support additional third-party sentation Foundation (WPF), and Silverlight development. while writing application code in Ruby. Instead, for CLR objects, IronRuby transTaking advantage of WPF from IronRuby lates Ruby method calls into the equivalent is easy. When the following code is executed, method name for the CLR: $list = ArrayList.new you can have a fully functioning WPF window $list.add_range([1,2,3,4]) created from IronRuby. You still must reference Here I am accessing the AddRange method mscorlib and the two WPF assemblies shipped following Ruby’s approach, which is lower case with the .NET Framework 3.0, as you did with Figure 1 Using IronRuby to Create a with words separated by an underscore. If you C#, using the require statements: WPF App prefer, you can keep with the CLR naming require 'mscorlib' convention as the method name still exists from Ruby: require 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' require 'PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' $list.AddRange([1,2,3,4]) At this point, a fully interactive WPF window will be displayed with the click event correctly wired up as shown in Figure 1. I interacted with the .NET Framework in the same way I would interact with Ruby libraries. One of the core principals set out by John Lam and team was to stay true to the Ruby language. This is an important principal for adoption by current Ruby developers, who won’t want to change the way they create Ruby applications just because they’re moving to IronRuby. Instead they can access all the rich .NET code in the same way. You can now create and interact with the WPF objects. First, create aliases for all the objects you want to use. This makes the code cleaner, as you won’t need to access the object via its namespace: Window = System::Windows::Window Application = System::Windows::Application Button = System::Windows::Controls::Button Next, create a WPF window and give it a title: win = Window.new win.title = 'IronRuby and WPF Interop' Both work the same; it’s just a personal preference which to use. As I mentioned, Ruby infers the type of objects at run time, and this is the same when handling C# objects. Consider a series of C# methods that return different object types, while the same object is being returned, the method signature returns either the interface or the concrete type. Within my example, I have an interface that defines a single HelloWorld method: public interface IHello { string HelloWorld(); } msdnmagazine.com February 2009 59 http://www.msdnmagazine.com

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.