RubyObjC News.

Programming Nu.

November 16, 2007

The future of RubyObjC is here at the web site that I built for a project that directly addresses the intrinsic problems of bridging languages with deeply different implementations and cultures. For my applications, neither RubyObjC nor RubyCocoa did this adequately, and what was needed was a significant reworking of either the Ruby or Objective-C infrastructure. Because the Objective-C community has produced deeper, more professional, better-performing, and higher-quality components, I chose to base my work on Objective-C, and instead of using Ruby, I began building a simple interpreted object-oriented Lisp that was designed from the start to work well with Objective-C. In the process, I found that there were many preexisting Objective-C components that I could reuse, and that plus the power advantage of a Lisp over Ruby meant that I could do more with even less code. The result is online and open source, and you can find it at programming.nu.

RubyObjC 0.4.0 Released.

June 10, 2007

For details, see the release history page. There are also several new examples.

Also, RubyObjC is now open-sourced and released under the Ruby License. You can get the source from the subversion archive on RubyForge.

RubyObjC 0.3.0 Released.

February 16, 2007

This version contains some changes to the way that Ruby methods are added to the Objective-C runtime. In earlier releases, these changes were optional, but now they are required. Previously, RubyObjC used Ruby's method_added callback to detect when new methods were added to classes and then attempted to automatically add handlers for them into the Objective-C method tables. But since not all Ruby methods are named according to the necessary convention, sometimes methods would be silently omitted. To avoid confusion, RubyObjC makes it explicit: any Ruby methods that are to be called from Objective-C must be written in a specific style, as described in the RubyObjC guides.

RubyObjC guides are online.

February 2, 2007

I've put some notes online to answer frequently-asked questions and to sketch out some things that I've learned as I've worked with RubyObjC. You'll find them in the RubyObjC guides.

Announcing RubyObjC.

January 1, 2007
Los Altos, CA

At last year's RubyConf, I showed a few people an early version of an all-new Ruby/Objective-C bridge that I was writing. I had started it in late August. It was partly a response to a few problems I was having with RubyCocoa, partly to try out improvements in the Objective-C runtime interface, partly to learn more about Objective-C and Ruby, and partly because I just wanted to do some things differently. The result is RubyObjC.

I built RubyObjC from the bottom up, starting with a set of Ruby wrappers around the Objective-C runtime API. Originally it was only a research project, but as it developed, I found that each bit of Ruby access I added made it easier to do more. Eventually I had a bridge that supported all of the examples I had developed for RubyCocoa -- and more.

Besides using RubyObjC for my own development and consulting projects, I've decided to make it available publicly. For now, it's a binary release available as a Ruby gem and includes a Rake task for building Cocoa applications.

Once you've tried that Rake task, you might never go back to Xcode, except to read the Cocoa documentation, of course. Xcode has a nice built-in browser that you can use to read a lot of great Cocoa documentation. Until I figure out how to run that browser outside of Xcode, Xcode is still in my dock. But I've found that Xcode obscures the ease of working with Cocoa, and that Rake makes it clear. Read the Rake task for yourself and see. It uses the exact same compiler as Xcode (gcc), but specifies everything explicitly and in one place. And if that Rake task doesn't do exactly what you want, you can easily see how to write one that does. Compare that to all the time you've spent clicking around in Xcode (or worse: hand-editing Xcode project files).

RubyObjC also includes a simple application generator. In the same way that the "rails" command can get you started with a rails app, the "rubyapp" command will create a skeletal Cocoa application. If all of your application code is in Ruby, then the RubyObjC Rake task will build a universal application with no compilation necessary. If you have some Objective-C code, then it will be compiled and linked to build a universal application.

RubyObjC code looks a lot like code written for RubyCocoa, but is a bit more strict and low-level at times. That is to give programmers more direct control over the bridge and shows my bias toward getting reliable software rather than interesting the masses of Ruby programmers, some of whom dislike underscores at the end of method names and having to specify the types of method arguments and return values. But I built RubyObjC because I had some software that I wanted to write with it, and to me, the most beautiful software is software that works reliably.

I also don't think we should hide Objective-C. I think it's a great language that is useful for a lot of things besides desktop application development. So watch for ports of RubyObjC, and get ready to meet the marvelous Objective-C runtime. With RubyObjC's detailed Ruby interface, I think you'll find that introduction a breeze.

I have some examples that I will be putting online to show RubyObjC in action. Some are brought over from my RubyCocoa site, but others are new. Some of them are things I could never get working with RubyCocoa. Some also illustrate my attempts to go without Interface Builder. If you read my "Mastering Cocoa With Ruby" article, you'll know that I'm not a big fan of IB, at least not as a programming tool. "Less code" is good, but that doesn't imply that "no code" is better, especially when that involves endlessly clicking around in a graphical user interface just to be sure that everything has been configured correctly. There is a better way, and RubyObjC can help you see it.

So again, for now, RubyObjC is available in a binary release packaged as a Ruby gem. The public release is licensed for noncommercial use only. If you would like to use it commercially, contact me and we can discuss other arrangements. RubyObjC makes things that were once impossible possible. Try the examples and see. RubyObjC gives power to Ruby and makes Cocoa development a lot a lot easier.