On Fri, Jul 17, 2009 at 10:19 PM, Yehuda Katz<wycats / gmail.com> wrote:
> This test passes in 1.8 but not in 1.9 because of the change in behavior.t
> also clearly articulates the reasonfor the 1.8 behavior: it is morehe
> expected behavior. One of the things that's great about Ruby is that it
> focuses on programmer understanding, even if that is sometimes slow. Thiss
> a case where the programmer expects to see a constant but it is being looked
> up somewhere the programmer knows nothing about. I think it is clear that
> the old behavior is better, even if it is harder to implement. Additionally,
> both JRuby and Rubinius were able to implement the old behavior in a
> compiled system, so it should be possible.

As I understand it, this change was actually made *on purpose*. A key
example of when this is useful is for programmatic class definitions:

class Foo
  Bar = 1
end

xyz = Class.new(Foo) do
  puts Bar
end

Under Ruby 1.8.x, this raises an error because Bar can't be found.
Under 1.9, because constant lookups within a block get re-scoped to
their actual execution context (a subclass of Foo), it prints out '1'.

This is actually very useful, since constants now actually follow the
runtime scoping of their execution context rather than only following
their lexical scoping. But I also agree that it's a fairly major
breaking change, since it can drastically change existing code that
expected the old behavior:

I don't have a good solution for you. This is one of those language
changes that makes existing libraries really hard to support across
Ruby versions. Of course I and others have argued for a way to isolate
version-specific releases in RubyGems, but that has regularly been
shot down. So as it stands today, you can't release a separate 1.9
version of a RubyGem, even though changes like this may make it very
difficult to support a single gem portably.

- Charlie