It is also possible to call Ruby from Objective-C. In fact, this is what happens nearly every time Ruby code is executed in a RubyCocoa application. The main event loop of a Cocoa application is written in Objective-C: with RubyCocoa, the Objective-C framework code calls Ruby implementations of class functions. But the power of this goes further. Since Ruby code can call Objective-C code and Objective-C code can call Ruby code, we can freely mix the two languages in our applications. We get to use Ruby’s high-level data structures and programming constructs and when needed, we can write fast C code using Objective-C.

Here’s an example that illustrates calls back and forth between Objective-C and Ruby using RubyCocoa.

First, the Objective-C class interface description (we’ll put it in a file called Client.h):

#import <Cocoa/Cocoa.h>

@protocol Helper
- (NSNumber *) helpfullyAddX:(NSNumber *)x toY:(NSNumber *)y;
@end

@interface Client : NSObject {
   id helper;
}
- (id) helper;
- (void) setHelper:(id)helper;
- (NSString *) name;
- (NSNumber *) addX:(NSNumber *)x toY:(NSNumber *)y;
@end

Here is the Objective-C class implementation (Client.m):

#import "Client.h"

@implementation Client

- (NSString *) name {
    return helper ? [helper name] : @"Client";
}

- (id) helper {
    return helper;
}

- (void) setHelper: (id) h {
    [h retain];
    [helper release];
    helper = h;
}

- (void) createHelper {
    Class helperClass = NSClassFromString(@"Helper");
    id helperInstance = [[helperClass alloc] init];
    [self setHelper:helperInstance];
}

- (NSNumber *) addX:(NSNumber *)x toY:(NSNumber *)y {
    return helper ? [helper helpfullyAddX:x toY:y] : [NSNumber numberWithInt:0];
}
@end

Finally, here’s the Ruby code:

require "osx/cocoa"
require "client"
OSX.ns_import :Client

class Helper < OSX::NSObject
  def name
    "helper"
  end
  def helpfullyAddX_toY(i,j)
    puts "helper arguments are of type #{i.class} and #{j.class}"
    i.to_i + j.to_i
  end
end

client = OSX::Client.alloc.init

puts ">>> testing client without helper"
puts "name: #{client.name}"
puts "sum:  #{client.addX_toY(5,2)}"

puts ">>> testing helper"
helper = Helper.alloc.init
puts "name: #{helper.name}"
puts "sum:  #{helper.helpfullyAddX_toY(5,2)}"

puts ">>> testing client use of helper"
client.setHelper(helper)
puts "name: #{client.name}"
puts "sum:  #{client.addX_toY(5,2)}"

puts ">>> repeating; now the client looks up the helper class by name and makes its own helper"
client.createHelper
puts "name: #{client.name}"
puts "sum:  #{client.addX_toY(5,2)}"

The example shows two ways of referring to Ruby objects from Objective-C. In the first case, we have our Ruby code tell our Objective-C code about itself—Ruby code sets the helper object of our Objective-C object. In the second case, the Objective-C code looks up our Ruby helper class by name using NSClassFromString. It is important to remember that to be visible from Objective-C, any Ruby class (1) must be derived from OSX::NSObject, and (2) its definition must have already been evaluated by the Ruby interpreter.

You may have noticed that we call to_i on each of the arguments to helperAddX_toY. When we call Ruby from Objective-C, each numeric argument is passed as an NSNumber. The RubyCocoa bridge currently requires that every argument in calls from Objective-C to Ruby be an NSObject. Exceptions are made for many Cocoa (Framework and AppKit) messages, but they are hard-coded into the RubyCocoa bridge. The numeric value returned by helperAddX_toY is automatically converted back to an NSDecimalNumber by RubyCocoa.

void Init_client(){}

gcc -o client.bundle -bundle -framework Foundation Client.m

require 'client.bundle'

require 'client'

When you run the example, you should see the following results:

>>> testing client without helper
name: Client
sum:  0
>>> testing helper
name: helper
helper arguments are of type Fixnum and Fixnum
sum:  7
>>> testing client use of helper
name: helper
helper arguments are of type OSX::NSDecimalNumber and OSX::NSDecimalNumber
sum:  7
>>> repeating; now the client looks up the helper class by name and makes its own helper
name: helper
helper arguments are of type OSX::NSDecimalNumber and OSX::NSDecimalNumber
sum:  7

If you have any problems, download this tar file that contains everything. If you still have problems, email me, there’s probably something online here that I need to fix!

Be sure to use irb to explore further. This is just the beginning.

The previous section showed an example where a Ruby class is derived from NSObject. You can subclass other Cocoa classes and your own Objective-C classes as well.

OSX.ns_import :Sprite

You can then use your class inside Ruby. You’ll need to refer to it with the OSX:: prefix unless you’ve used include OSX somewhere earlier in your session or program to get inside the OSX module namespace.

class RubySprite < OSX::Sprite
  def hello
     "hello" 
  end
end

s = RubySprite.alloc.init

You also need to know a few other important things:

Overriding methods

   ns_overrides :drawRect_
   def drawRect(rect)
       super_drawRect(rect)
       ... custom code...
   end

In the example above, the drawRect: method of the parent class is being called by the name super_drawRect.

Initializing objects

As noted previously, when Objective-C-based objects are created, the Ruby calling code must use the Objective-C allocation and initialization methods. So instead of calling mySprite.new, Ruby code must call mySprite.alloc.init.

A Ruby class will often require additional initialization. When overriding initializers, be sure to call the superclass’s initialization function. If you have overridden the superclass initializer (let’s assume it’s init), then call it using super_init. If you have written a new initializer and have not overridden the superclass initializer, then you can simply call it by name.

Finally, don’t forget to return self! It’s a Cocoa requirement that all initializers return the object that was initialized. It’s easy to forget this, and serious problems will result when you do.

I decided to include this section for completeness, but currently I don’t know of any way to write Objective-C subclasses of Ruby classes. I also can’t think of a good reason to do so. If you can help me with either, please email me!

Objective-C and Ruby are both children of Smalltalk, but they have grown up separately. There are a few ways you can trip over the gap between them.

Although method calls are bridged automatically, Objective-C and Ruby use different classes to represent similar kinds of things. When a Cocoa function returns a string, it returns an OSX::NSString and not a Ruby String. irb is a great way to explore and debug problems. When you can’t use irb, use puts or OSX::NSLog to write the class of an object (which you can get in Ruby by calling object.class).

Also, watch out for name conflicts between Objective-C and Ruby. If you try to call an Objective-C method when there’s a Ruby version with the same name, the Ruby one will get called instead. And since the RubyCocoa bridge code won’t get called, you won’t get any warning about this! I’ve run into this problem a few times when I’ve tried to call functions named load and display. To make sure that you get the Objective-C versions, add the oc_ prefix (that’s why you’ll sometimes see oc_load and oc_display in my RubyCocoa examples).

Name conflicts can also occur among source files. Watch out for file names that may be the same as files in Ruby libraries. I recently put some code in a file called “delegate.rb”, but on my local system, this file was masked by /usr/local/lib/ruby/1.8/delegate.rb.