Lähettäjä: "Charles Mills" <cmills@freeshell.org>
Aihe: Documenting ruby.h and intern.h (was rb_const_get documentation)(...)
> >VALUE cGlit = rb_const_get(rb_cObject, rb_intern("GLIT"));
> >VALUE cGlitVec = rb_const_get(cGlit, rb_intern("Vec"));
> >
(...)also you can go:
VALUE cGlitVec = rb_path2class("GLIT::Vec");On a side note it would be nice if all the functions, structs, typdefs,
macros and variables ruby.h and intern.h were documented. I would be
willing to take part in an effort to do this. Anyone else?
Probably need to start out by figuring out the best way of going about
it. A format would have to be decided on and also a way to cross
reference/search/interact with the documentation (so people with
questions about resolving constants would be able to find answers).
Seems like there would need to be a central place to put the
documentation. SVN repository, wiki, ...?
Seconded, along with a more complete how-to for Ruby extensions
(unless Pickaxe 2 substantially expanded their coverage?). I can
volunteer some time (unless, of course, someone is paying:).
I played around with using Doxygen for doing this, but I think it would
be better if the documentation was external to the .h files - mainly
because I don't think Matz and others would like having pages and pages
of docs embedded in these files and because keeping the files with
embedded docs in sync with the original .h files would be a nightmare.
On the other hand a format like RDoc or Doxygen is good because there
isn't a huge amount of mark up to learn... well, I guess other people
will have some suggestions for this...
Just a Wiki would probably do for information on usage of the
functions, initially, with maybe some preliminary grouping (I just
dislike Doxygen, it's not very clean to navigate through).
In favour of Doxy (or rdoc), the people actually programming might be
more inclined to update the docs if they were present right there in
the source.
In either case, I'm sure www.ruby-doc.org would have the space?
-Charlie
E