So, I’ve created a bit of a mess with regards to the naming of different versions of FXRuby and am trying to decide how best to solve that problem.

When FOX 1.2 was released, Jeroen made a number of API changes in order to promote more consistent naming conventions. For example, classes with names like FXScrollbar and FXStatusline were renamed to FXScrollBar and FXStatusLine, and everything was moved into a C++ namespace. FXRuby 1.2 inherited these changes and, as a result, threatened to break a lot of code in the process. Your compiler will loudly tell you that you’ve misspelled a class or member function name in your C++ code, but such errors won’t be discovered until runtime in an interpreted language like Ruby.

In a perhaps poorly thought-out workaround to this problem, I renamed the Ruby extension from “fox” to “fox12″ when FXRuby 1.2 was released (see the discussion in the mailing list archives). Code that was written against the FXRuby 1.0 API would continue to require 'fox' and would continue to work as before, using the installed version of FXRuby 1.0. Code written against the FXRuby 1.2 API would instead require 'fox12'. And this approach more or less worked, and wasn’t all that confusing, considering that there were only two choices of FXRuby to pick from.

Fast-forward a few years, and we’ve now seen both FXRuby 1.4 and 1.6 releases. Neither of these releases made significant API changes as compared to FXRuby 1.2, and greater care was taken to promote backwards-compatibility. The confusing extension-naming convention was followed, however, which means that application programmers have to do some trickery in their code to ensure that a working version of FXRuby is require‘d into their application. Ideally, code that was written in the FXRuby 1.4 era should continue to work unmodified if FXRuby 1.6 is the only version that’s available, but that’s not the case — at a minimum, you’re going to have to go in and modify the require 'fox14' statement to read require 'fox16'.

RubyGems provides a mechanism (via the require_gem method) to deal with these versioning issues, but at the time we made this decision for the FXRuby project (back in the summer of 2004), that feature had not yet been implemented in RubyGems. And even if it had been available at that time, RubyGems wasn’t the de facto standard for Ruby library distribution that it is now, and it wouldn’t have made sense to depend on the user having installed FXRuby from a gem.

One of the happy side effects (well, happy for some) of the explosion of Rails over the last year and a half is that the acceptance and use of RubyGems has become much more widespread. I don’t believe RubyGems is part of the Ruby core (and probably doesn’t belong there yet), but it is part of the One-Click Ruby Installer for Windows, and anyone who uses Rails is likely to have installed RubyGems as well. So it’s reasonably safe, at this point in time, for me to assume that RubyGems is going to be available on any platform where Ruby and FXRuby are running.

So the question is, what’s the best choice going forward? Discussion on the RubyGems developers’ mailing list seems to indicate that the requiregem method is going away, and that it will be replaced (sort of) with a new gem method that “activates” a particular version of a Gem by placing its directory in Ruby’s $LOADPATH (but that doesn’t actually require anything.) On the other hand, that particular discussion has been going on since at least since May of last year and doesn’t seem to be quite resolved yet.

As O’Reilly might ask, “What say you?”