On Thu, 22 Mar 2001, Hal E. Fulton wrote:

> > I got to wondering today - what design philosophies/heuristics are
> > ruby folks out here employing to decide "Extension or pure Ruby code?"
> > 
> > NQXML is one of the more recent examples that springs to mind (great
> > stuff, Jim - thanks) in which the decision was to go with pure Ruby.
> > 
> > What factors do you consider?  How do you weigh them?
> > 
> 
> Colin,
> 
> This is just my opinion. 
> 
And here're some of mine:

> The only reasons I can see to implement an extension are (in order):
>    1. Need a low-level feature not accessible any other way (a good
>        reason, but perhaps a rare one);
>
This is a good reason although in the long run we might be better off
doing this stuff with a Ruby Inline module similar to Perl's Inline
module but adding features so that you can do something like (ie. some
smart logic to automatically "type convert" between Ruby and inlined
language and being able to mix inlined code with Ruby classes):

class MyExt
  def initialize(a1, a2)
    inline "C" {
       return INT2NUM(a1+a2);
    }
  end
end

Is anyone working on Inline?

>    2. Need blazing speed (a good reason and much more common)
>
This is a good reason and will probably continue to be so. However, IMHO
you should first do it in pure Ruby and then substitute the critical parts
in c or whatever.

>    3. Need/want to hide the source code from the user
(not that I >        necessarily condone this)
> 
We should do this with a wrapper/packager/freezer instead... Watch out for
matz next-gen bytecode interpreter and RubyVM where this will be easier.

Regards,

Robert