Ruby entities and relationships?

Can anyone point me to an overview or ontology of the major
entities and relationships in the Ruby language? I’m
digging a lot of this out of RDoc and assorted books, but I
haven’t seen anything that addresses this particular topic.

-r

http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

On Feb 21, 2007, at 1:52 PM, Rich M. wrote:

At 8:57 PM +0900 2/21/07, Harold H. wrote:

I’ve always liked this one:
http://phrogz.net/RubyLibs/RubyMethodLookupFlow.png

That’s a nice diagram. There’s a diagram in “Ruby for
Rails” that covers much of the same territory. What
I’m looking for, however, is something that covers a
wider swath than classes, instances, and modules.

What other ‘entities’ did you have in mind? Since
almost everything in Ruby is an object, there isn’t
much left after you’ve talked about classes, instances,
and modules.

Are you looking for something like a class hierarchy?
If so, you might want to take a look at some of the
diagrams at http://www.insula.cz/dali/material/rubycl/
or http://objectgraph.rubyforge.org/

Gary W.

At 4:38 AM +0900 2/22/07, Gary W. wrote:

What other ‘entities’ did you have in mind? Since
almost everything in Ruby is an object, there isn’t
much left after you’ve talked about classes, instances,
and modules.

My motivation is to extend RDoc’s coverage and utility.
Currently, RDoc presents the following information about
Ruby entities and relationships:

Names of Classes, Files, and Methods
Class or Module each Method is defined in
Comments for files and methods
Code/comment snippets for each method

I’d like to go in two directions. First, I’d like to add
coverage of more entities (e.g., Exceptions, Callbacks,
Variables) and relationships (e.g., which method looks for
which exception). Then, I’d like to store the information
in a computer-friendly form, such as a set of DB tables,
so they can be accessed by a Rails app, etc.

For now, however, I’m just looking for candidate Es and Rs.

-r

http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

On 22.02.2007 18:02, Rich M. wrote:

Ruby’s dynamic nature presents all sorts of obstacles, to be sure.

RDoc is handy, but it doesn’t provide anything like the feature set of
(say) Doxygen.

Well, you know the reason for this already. :slight_smile:

Good luck!

robert

On 2/21/07, Rich M. [email protected] wrote:

Can anyone point me to an overview or ontology of the major
entities and relationships in the Ruby language? I’m
digging a lot of this out of RDoc and assorted books, but I
haven’t seen anything that addresses this particular topic.

I’ve always liked this one:

hth,
-Harold

At 8:57 PM +0900 2/21/07, Harold H. wrote:

I’ve always liked this one:
http://phrogz.net/RubyLibs/RubyMethodLookupFlow.png

That’s a nice diagram. There’s a diagram in “Ruby for
Rails” that covers much of the same territory. What
I’m looking for, however, is something that covers a
wider swath than classes, instances, and modules.

-r

http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

On 21.02.2007 21:17, Rich M. wrote:

Names of Classes, Files, and Methods
Class or Module each Method is defined in
Comments for files and methods
Code/comment snippets for each method

I’d like to go in two directions. First, I’d like to add
coverage of more entities (e.g., Exceptions, Callbacks,
Variables)

Exceptions are tough since Ruby does not have checked exceptions. And
because of Ruby’s dynamic nature it’s practically impossible to
determine which exceptions can be thrown by a method.

Callbacks, not sure what you mean here. You can view every block passed
to a method as callback. What do you want to document about this?

Variables: if you refer to local variables I don’t see the point in
documenting them. They are completely private to a method and their
names can change without affecting any code outside.

and relationships (e.g., which method looks for
which exception).

By “looks” do you mean “has a rescue clause for”? That is certainly
easier to do than determining which exceptions are thrown by a method.
However, I think the latter info is much more useful as it affects the
caller.

Then, I’d like to store the information
in a computer-friendly form, such as a set of DB tables,
so they can be accessed by a Rails app, etc.

To do what? Sorry, I still don’t understand what you want to achieve.

Kind regards

robert

At 4:55 PM +0900 2/22/07, Robert K. wrote:

Exceptions are tough since Ruby does not have checked exceptions.
And because of Ruby’s dynamic nature it’s practically impossible
to determine which exceptions can be thrown by a method.

Ruby’s dynamic nature presents all sorts of obstacles, to be sure.
Nonetheless, there ARE some possibilities:

  • Rescue clauses can be recognized and tracked.
  • Exception use can be recorded in a logfile and analyzed.

In Callbacks, not sure what you mean here. You can view every
block passed to a method as callback. What do you want to document
about this?

I’m a bit vague about this myself. Certainly, if the program sets
up a callback to Module#method_added (etc), we can track this.

Variables: if you refer to local variables …

Agreed. Local variables are only interesting in so far as they can
be confused for method calls.

By “looks” do you mean “has a rescue clause for”? That is certainly
easier to do than determining which exceptions are thrown by a method.
However, I think the latter info is much more useful as it affects
the caller.

As noted above, determining which exceptions are thrown by a method
can be tracked through execution logging. Of course, we then get
into the usual problems of code coverage, etc. I’ve got some logging
code started for this sort of thing, but I’d rather concentrate on the
things that can be determined through static analysis, for now.

Then, I’d like to store the information in a computer-friendly form,
such as a set of DB tables, so they can be accessed by a Rails app, etc.

To do what? Sorry, I still don’t understand what you want to achieve.

As I said, my motivation is to extend RDoc’s coverage and utility. If
the information gathered by RDoc (etc) can be stored in an accessible
form (e.g., DB tables), it should be possible to build some Rails code
that can allow the user to browse it, diagram relationships, etc.

RDoc is handy, but it doesn’t provide anything like the feature set of
(say) Doxygen. Also, it pays no attention to information that can be
gathered from Rails apps: method references in rhtml files, conventions
in file naming, etc. So, the general plan is to gather the information
that I can, store it in a DB, and see what useful displays I can create.

-r

http://www.cfcl.com/rdm Rich M.
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development