Dear Mr. Matz,

While we are on the subject, is it a good idea to dig deeper into the Ruby
C implementation from the interface point of view?

What I mean is, for the Ruby language itself, I think you will make effort
so that the Ruby API is backward compatible in the future releases.  What
about the RUBY C API?  Are you going to make effort so that they are
backward compatible too?

Also, is there any defined set of "official RUBY C API"?  Is it only all
the functions/macros/structs listed in ruby.h and intern.h?

The reason is, for efficiency purposes, sometimes I may want to get to the
underlying C function directly, instead of calling "rb_funcall".  Probably
to be efficient, I have to define my own structures and
functions; however, often this is difficult as Ruby requires all
user-accessible objects to be of type VALUE.

Regards,

Bill
===========================================================================
Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> |variables we have three functions with unsimilar names?
> |
> |    rb_define_variable          - read and write
> |    rb_define_readonly_variable - read only
> |    rb_global_variable          - no read and no write
> |
> |Isn't it cleaner if we also have only a single function such as
> |"rb_define_variable (name, value, read, write)"?

> I could read your mind.  So I prepared you

>   rb_define_hooked_variable(name, var, read, write)

> But still, rb_global_variable is a different beast.  Unlike others,
> its "variable" means "C variables", which is not seen from Ruby.

> 							matz.