Chris Thomas wrote:


> The big technical problem (assuming that GNUstep perfectly replicates the
> Cocoa API, which I'm pretty sure it doesn't currently) is that the GNU
> Objective-C runtime and the NeXT Objective-C runtime -- although
> conceptually related -- are completely different in both API and
> implementation.
> 
> There's already a Ruby interface to GNUstep, called RIGS. It would be much
> easier to coordinate RubyCocoa with RIGS to reduce the number of
> incompatible source code conventions. (All of RubyCocoa is within an "OSX"
> module, for example -- I don't know how RIGS is organized).
> 
> I suspect you'll need to wait until GNUstep's interface is a bit closer to
> Cocoa, though.
> 
> Another alternative would be to write an abstraction layer that sits on top
> of both RIGS and RubyCocoa, isolating and bridging the differences between
> them. That could be a lot of work, however.
> 
> (BTW, A "fat binary" in Mac OS X parlance is a binary archive that contains
> one Mach-O file for each CPU architecture that the developer wants to
> support. Linux uses ELF executables, not Mach-O, so fat binary support is
> not helpful for this purpose.)
> 
> Chris
> 
> 
> .
> 
> 

As the author of RIGS (Ruby Interface to GNUStep) I think Chris
has the right approach for the moment. I don;t know how
RubyCocoa is organized so I'm speaking under the control of its
author here.

The first step would probably be to harmonize the naming schemasi
(like the top module name for instance). This is easy to do.

The second step is to abstract the layer that interact with the
underlying Objective C runtime. In RIGS this part of the code is pretty 
well isolated from the rest. SO clearly the work here is
to rewrite it for Cocoa and the Apple/NexT runtime.

As to whether GNUstep is at the same level as Cocoa (in terms of methods 
implemented) this does not matter in RIGS. The reason is that RIGS is
an entirely dynamic piece of code. It means that when you load RIGS it 
scans the GNUstep runtime, discover all the class and methods (not yet 
protocols) and automagically declare them in the Ruby runtime. So RIGS 
can adapt itself in real time to the platform it runs on.

Unfortunately I do not have a MAC OS X machine and can't port RIGS
to Cocoa but if Hisakuna FUJIMOTO San (the author of RubyCocoa) is 
willing to spend some time on it with me we can certainly make
progress in aligning RIGS and RubyCocoa and why not merge them in the 
long run.


Laurent