"Charles Hixson" <charleshixsn / earthlink.net> wrote in message
news:200208171345.24287.charleshixsn / earthlink.net...

> I have some things I want to do (quite a large number, actually) that can
be
> completely specified at compile time.  Others where I at least know the
type
> and length of the parameters.  And others where things are pretty open,
where

The main difficulty is that Ruby's classes are not fixed at compiletime.
This is much more difficult to deal efficiently with than the lack of types.
You could do some typeinference and implement an efficient solution with
fallback to generic types. But the method lookups in a dynamic world is more
tricky. It can be done but you eventually get so much overhead that bytecode
is almost as efficient.

You need some kind of Class.freeze method to indicate you do not intend to
change it anymore for efficient compilation.

Another more problematic issue is that C extension modules has full access
so you can't do any safe compile time analysis. You could make assumptions
and throw exceptions on "badly" behaved extensions.

A safer solution is an alternative C interface that only calls simple
functions and defines the classes in Ruby with "def external("my C
function") (x, y) is also a possibility. (callback also needed, but no
reflection).
This is the kind interface that OCaml has, and does allow external C
functions to become class members.

Mikkel