On Sat, Aug 03, 2002 at 03:35:38PM +0900, Phil Tomson wrote:
> 
> Then it hit me... we alreay wrap all of our C++ objects with Swig so that 
> we can do unit testing in Ruby using Test::Unit so why not take it a step 
> further and use Ruby to tie together all of our C++ objects.  The idea 
> being that instead of embedding Ruby into our C++ application we'll use 
> Ruby to manipulate the objects defined by C++.  All of the comutationally 
> intensive stuff is already done in those C++ classes so there won't be any 
> performance hit.  We won't define a main() function on the C++ side, we'll 
> just create the shared library from the swig wrappers and instantiate 
> those objects in Ruby.
> 
> So, I wrote the parser for our input file in Ruby in about an hour (it 
> would have taken substantially longer in C++) and started creating the 
> frontend for the C++ part of the application in Ruby.  I actually think 
> this will give us a lot more flexibility when compared to the alternative 
> of embedding Ruby into the C++ app.  And since we were already using Swig 
> for testing purposes it's not costing us any extra time and we don't need 
> to take any extra time to embed Ruby.
> 
> So, why embed when you can swig? (hoping to start a philosophical 
> discussion :-).
> 
You are doing just what I would have done.
My 'simple' philosophy would be to use ruby as the base language.
If all code was new, write it all in ruby. Where there are slow
parts, implement those in a faster language. Since your computationally
instensive stuff was already written in C++, there is no rewrite involved.
And swig just helped you to link it into ruby.

So, even though you are in a mixed language environment, you construct
your project around ruby which is much more flexible. 
Setting the project up this way would probably mean that ruby would be 
the arbiter between languages if your mixed lang environment had
more that two languages. 


-- 
Jim Freeze
If only I had something clever to say for my comment...
~