"Hal E. Fulton" wrote:
> ...
> > |If we're not going to have both, I'd vote for: Change the meaning of the
> > ||...| notation, fix all the old code that it breaks, and move on.
> >
> > This is a price for a mistake I made.  I feel really sorry that YOU
> > have to pay the price.
> 
> Speaking only for myself... this guilt is surely misplaced.
> 
> You gave us a great language. OK, it has a quirk or two.

As for me, I accept the apology. I did spend considerable time
trying to figure out this particular quirk. Time isn't free.

On the other hand, I agree to allow old code to break...

... 
> There comes a point when "backward" compatibility... is exactly that.
> 
> The syntactic beauty of Ruby is assured the same way the semantic
> beauty is... by looking ahead, not back.
> 

I agree with you on this.  If something has been determined as
a mistake, I would rather it be fixed and require all past code
to continue to use the older version of ruby until they can be updated.

** Don't we already make this decision everytime we upgrade Ruby? **

When we upgrade from say 1.6.2 to 1.6.3, our code is already subject
to incompatibilities. That's right, 'patch level' changes are not even 
fully backwards-compatible, which is why I maintain separate versions 
of ruby 1.4.0, 1.4.1, ... 1.6.3.  And each script I make is made to run 
with a particular patch level (usually the most recent one).

#!/usr/local/bin/ruby163

I don't have time to go back and change all scripts when I upgrade
from 1.6.x to 1.6.(x+1), and I can't really afford to upgrade the
default way and watch random scripts stop working right.

Just consider the blade ruby-talk system, which already uses
multiple versions of ruby. Wonder why it hasn't been distributed yet?

This is also an issue with other languages, such as perl, python, or php.

RCR?
----
I think it would do everyone a favor to change the default installation
of Ruby to allow concurrent multiple versions of Ruby to exist.
That means, instead of Ruby automatically installing 1.6.3 over 1.6.2,
to install it separately such that they coexist.  This would also facilitate
a versioning system to work with Ruby.  Sure, you can do this now by
manually installing it to a particular destination, but why not make
it do that by default?  Less surprises for those with scripts that
happen to be using one of the non-backward-compatible changes that
occur between 'patch-level' versions (aka TEENY). Not everyone can do 
their own installs, either. And if you wrote an old script that didn't
check the ruby version, you easily fix it by changing the shebang on top.


I think this will help pin down a way to handle versioning in scripts,
both of which are a prerequisite to building a decent CPAN- or debian-like 
system for creating/managing RAA.succ. 


Guy N. Hurst

-- 
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            (757)623-9688 FAX 623-0433
PHP/MySQL - Ruby/Perl - HTML/Javascript