On Tue, 20 Feb 2001, ts wrote:

> J> I must say that despite the fact that this would change incompatibly the
> J> language in a big way, I like very much this proposal. Much cleaner than
> J> current ruby semantics, in my opinion. But probably not feasible :(
> 
>  and scripts in RAA (rwiky, tmail, erb, etc) perhaps it's faster to rewrite
>  completely RAA :-(

Or invent an upgrade mechanism to take care of any language changes that
happen in future.

Ruby programs can specify the version of Ruby they're written for, then
there's a few different ways of handling it. Scanning code for stuff that
will break, backwards compatibility modules, auto-conversion, etc.

I think the main problem is that there's no one place where all the code
can be handled together. If a part of Ruby gets changed, unpacking files
from RAA, building, testing and re-packing isn't feasible.

What about a giant source code tree where everything Ruby can be compiled
in one go, like BSD's "make world" scheme?

This would allow a number of interesting possibilities. One thought that
springs to mind would be apt-get style functionality for Ruby modules,
which could take advantage of a unified unit testing scheme to fetch the
reqested module, compile, unit test and install.

This would allow a core change to be rippled out to modules in one hit.

-- 
  spwhite / chariot.net.au