From: Dave Thomas <dave@...>
Date: 2003-01-03T00:38:28+09:00
Subject: Compatibility (was Class.inherited)

On Thu, 2003-01-02 at 08:48, Yukihiro Matsumoto wrote:

> I'd like to hear about when, where, what names are suitable for
> class/method definition hook methods, in addition to above methods?
> Timing of existing hook might be changed after the discussion.

This raises a somewhat bigger question.

I've now got a fair amount (probably 50kloc) of Ruby in production. Most
of this runs on 1.6.7. I'm frankly nervous about upgrading it to 1.8
because of the various changes in the language. Particularly worrying
are changes where some syntax is valid in both the old and new Ruby, but
the semantics are different. The .inherited change that sparked this
thread is one example, changes in precedence in rescue andling is
another. I've noted others that have passed by on the list.

As Ruby moves from being a hobby language into something that people use
to write serious production code, I'm wondering if we need to stop and
consider the implications of incompatibilities such as these. We could
give ourselves a serious black eye if we were to ship a new release of
Ruby that stopped some major and publically visible application from
working.

As a starting point for discussion: how hard would it be to make it a
rule that all incompatible changes are introduced in two phases. In the
first, the interpreter would announce that the behavior will change, and
then in the second (say 3 months later) the change will be introduced.
That would allow us to run our existing code against the interim
release, and give us time to fix things up before the change is made.


Cheers


Dave