Hi,
Using Tcl a long time ago, I found it relatively easy to use Tcl as a
wrapper of my C++ objects/functions. Basically, the development and
design of the C++ objects/functions themselves were relatively independent
of Tcl.
Using Ruby, to be able to interface Ruby with the underlying C
objects/functions, I found that (at least until now), based on the
examples shown in the Pickaxe book, that the design of the C
objects/functions is highly affected by the Ruby requirements on the Ruby
object model and Ruby function calling convention. This makes the
underlying C objects/functions less efficient than, say, writing the
application purely in C. But of course, I want to be able to “drive” the
C core using Ruby.
One idea that I am currently thinking is to create only a single Ruby
class, say class Pointer, that will contain at least: a pointer to the
underlying C data, a const char* that determines the actual object
type/class, and the “method_missing” function (and probably some other for
the inheritance).
When a user (using Ruby) is really interfacing with an object, then the
method_missing() is invoked, it determines the actual type of the object,
and calls the appropriate method for the object. When the user does not
interface at all, everything will be mostly in C. Therefore, when the
user does not interface, the code will be faster, but when the user does
interface, the code in general will be slower, than that in the
"classical" Ruby-C interface design.
The only unavoidable junction between C and Ruby is Ruby gc. Probably I
will (and have to) maintain my own array/heap for all the mark and free
functions for all those “Pointer” objects.
Does this sound like a good idea? Does this minimize the dependency of C
on Ruby? Will this make the maintanance easier when the Ruby internals
are changed, as the C codes have minimum dependency on Ruby? Has anybody
ever done large-scale integration between C and Ruby? Should I use C++
and Ruby instead?
Regards,
Bill