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

Hi,

At Wed, 5 Jun 2002 04:03:51 +0900,
Sean Chittenden wrote:
> 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.

Basically I guess it's good.

> > 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.

I've thought about it too, but couldn't conclude.
Renaming/moving files breaks backward compatibility for
extension libraries (and also annoys CVS).

> 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

Another way, creating stub headers $(archdir)/ruby/hash.h just
have `#include <hash.h>', and applications include ruby/hash.h.

-- 
Nobu Nakada