From: Dave Thomas <Dave@...>
Date: 2000-02-22T23:21:13-06:00
Subject: [ruby-talk:01541] Re: Ruby library modules and documentation

The following message is a courtesy copy of an article
that has been posted to comp.lang.misc as well.

"Conrad Schneiker" <schneiker@jump.net> writes:

> It might be a good idea to document these as not being further documented
> and to individually identify which ones are obsolete (and its successor),
> and which ones of the toys or perlish ones that others would be free to turn
> into something more useful (unless there are problems with backwards
> compatibility).

You know, I've been thinking that it might even be a better idea to
reorganize the current library somewhat.

Right now, there's stuff in lib/, some of which is useful, some not
so. Then there a heap of useful stuff in RAA.

So, I'm thinking that maybe there needs to be four library trees:

   supported, distributed        -- final, observer, etc
   unsupported, distributed      -- English, ..
   supported, not distributed     -- irb, benchmark
   unsupported, not distributed  -- ?

To qualify for the 'supported' category, a library module must:

1. Be documented with rdtool

2. Install automatically

3. Have a set of regression tests

4. Pass those tests with the currently supported release of Ruby

5. Fit in to the library directory hierarchy (which is yet to be
   defined, although matz is starting to migrate some stuff into
   lib/net/).

This last point is important. As the size of the library grows,
keeping it organized will become a challenge unless we impose some
structure from the start.

The nice thing is, all these criteria can be tested automatically as
part of the overall Ruby testing process, so we can actually cut down
on effort at the same time we add value.

As the current number of library modules and RAA entries is relatively 
small, this is a great opportunity to set some standards that will
make Ruby an easy language to _manage_ on user's systems.


What do people think?

Regards


Dave