[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>

33 messages 2000/02/08

[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>

Conrad writes:

13 messages 2000/02/15

[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>

17 messages 2000/02/19
[#1544] Re: Ruby/GTK and the mainloop — Yasushi Shoji <yashi@...> 2000/02/23

Hello Ian,

[#1550] Re: Ruby/GTK and the mainloop — Ian Main <imain@...> 2000/02/23

On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:

[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>

((FYI: This was sent to the Ruby mail list.))

10 messages 2000/02/19

[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>

The following message is a courtesy copy of an article

12 messages 2000/02/25

[ruby-talk:01541] Re: Ruby library modules and documentation

From: Dave Thomas <Dave@...>
Date: 2000-02-23 05:21:13 UTC
List: ruby-talk #1541
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

In This Thread

Prev Next