Ruby 1.9旨在对Ruby语言本身及核心类库进行修改完善，在经过了一年多的试验以后，终于在2007年的圣诞发布了——版本为1.9.0。
一些Ruby程序员将Ruby 1.9的发布看做是迈入Ruby新版本的标志性事件，但他们却发现在1.8版本和1.9版本语言之间的刻意不兼容性会导致原有Ruby代码无法工作。这个发现迅速成为了ruby-talk邮件组上讨论的话题。
其实真正的问题是，Ruby 1.9.0发布的原因以及其与Ruby 1.8之间的关系并不完全被Ruby社区元老们所了解。Matz在新版本发布前的几个月里在ruby-core邮件组里有过明确的说明，在一篇圣诞前一天的帖子中，他写道：
◆发布的版本是1.9.0，而不是我们预先声明的1.9.1。这表明它并不像我们期望的那样稳定，但是所有的不兼容性修改都已经完成了。
◆1.9版本与之前的版本是不兼容的。你的应用可能不会正常工作。移植的方法（或者移植工具）在第一版中不会提供。
而不幸的是，这些并没有出现在他在ruby-talk上的官方的发行声明中。
Dave Thomas在1.9.0发布后不久马上就在博客文章中给出如何看待及使用Ruby 1.9的意见。他的建议是在安装Ruby1.8的同时安装Ruby1.9，并开始对已有代码的兼容性进行检查，以便使其与Ruby 1.9兼容。
在最近，当Matz被问及何时Ruby1.9能够达到开发状态的时候，他说：
我们不知道。我们真的希望这一天早日到来。但是这涉及到非常多的因素。唯一的好消息就是，1.9的标准已经在上个圣诞节基本上确定了。
除最终确定标准以外，将Ruby 1.9用于实际生产还依赖于一个1.9的兼容版本，这也是Ruby应用的应用基础。Rails核心团队正在致力于改进Ruby 1.9的兼容性，众多gems和插件的开发者们也同样在努力。1.9兼容性的实现才是1.9.0发布的真正标志。
这些开发者们中的一些人也通过文档的形式说明了Ruby1.9对其代码的影像。其中的两个干得不错：一个是Sam Ruby关于对REXML的修改使之兼容的描述；另一个则是James Edward Gray II的类似文章，里面介绍了对FasterCVS类似的努力——从而实现了Ruby1.9标准库中对旧版CSV的替换。后者还给出了一系列有价值的经验和建议，比如：
◆Ruby1.9消除了通过“:”在if、unless和case语句中来代替关键词then的使用方法。
◆一些反射方法，例如instance_variables和constants，不再返回字符串数组，而是返回符号数组。
◆索引一个字符串的时候，比如"abc"[0]，会返回一个单字符的字符串，而不是返回一个整数。
◆Enumerable#zip有两方面修改。调用时没有块参数的时候，返回变成了一个迭代器而不再是数组；而在Ruby1.8中[1, 2, 3].zip(%w{a b})产生的是[[1,'a'], [2, 'b'], [3, nil]]，但在Ruby1.9中，因为前面提到的改变，[1, 2, 3].zip(%w{a b}).to_a的结果变为[[1,'a'], [2, 'b']]，即多余的元素会被接收者略过。这在ruby-core邮件组中有一系列讨论，看上去这些修改中的一个或者全部可能在1.9最终标准发布以前会修改成以前的样子。
Ruby1.9还为用户展示了许多颇为深奥的Ruby特性供选择。一些特性如延续机制等目前已经移出了核心并成为标准库的一部分。
另外，Ruby1.9提供了对编写代理类更好的支持。在Ruby 1.9以前，一些第三方ruby库使用Jim Weirich的BlankSlate类或者其衍生版本来实现一个最小类，最小类比Object的方法少得多，以至大部分的方法都会触发method_missing的回调。BlankSlate程序化地移除了许多继承的方法。Ruby1.9有一个新类叫做BasicObject，它实现了一个方法的最小集合（!、!=、==、equal?、singleton_method_added、singleton_method_removed和singleton_method_undefined），简化了代理类的编写。另一方面，在ruby-core还有一些是否需要更多的方法，如instance_eval的讨论。
总而言之，Ruby1.9的工作依然在进行当中，它依然还是一个开发版本而不是一个生产版本。1.9.0版的发布给了社区一定的冲击，来促使大家更加认真的来看待“新的”Ruby，但是Ruby1.9的成熟和社区能够准备好通过Ruby1.9进行更多的生产开发尚需时日。Dave Thomas就此说道：
Matz将1.9版本发布为一个开发版本，其中一个好处在于：我们有足够的时间去应对应用的迁移。
【相关文章】
相关文章
