Re: rb_hash_has_key() and friends non-static...

> > > > As for splitting out the declarations into its own header, that was
> > > > just something I did as it would provide a very convenient way of
> > > > grouping and documenting the C API inline with the headers.  Can
> > > > someone please comment on either?  -sc
> > > 
> > > The name "ruby_hash.h" doesn't seem so good, for me.
> > 
> > How about just "hash.h" ?  It does seem like overkill to have "ruby_"
> > in there.  -sc
> 
> How about other data structures, all headers like "array.h",
> "string.h" and so on?  What's the reason they should be
> splitted from "intern.h"?

Documentation primarily and ease of use of the API.  intern.h would
include rb_*.h so Ruby's core wouldn't have to change, but as a module
author or someone reading my code, if I include ruby.h and rb_hash.h,
then it's pretty obvious that I'm using ruby and its hash data
structure.  For people reviewing the code, if they want to see
anything and everything that's publicly available for the Hash data
type, they'd just have to look at rb_hash.h.

> > > The name "ruby_hash.h" doesn't seem so good, for me.
> >
> > How about just "hash.h" ?  It does seem like overkill to have
> > "ruby_" in there.  -sc
> 
> How about file system name conflicts? -> with ruby_ you atleast can
> guarantee that when the header is found by the compiler it's the
> correct one. The other approach is to have them all in a ruby/
> directory in the include directory.

Good point.  Either works for me.  I used ruby_ because it is
consitent with the yacc rountines and that has more external/global
consiquences, however rb_ is consistent with Ruby's internals.
::shrug:: Matz should probably chime in.  :~)  IMHO, rb_ would be
consistent with the way that Apache handles this.  -sc

-- 
Sean Chittenden