On 6 Jul 2010, at 10:56, Run Paint Run Run wrote:

> Issue #3140 has been updated by Run Paint Run Run.
>=20
>=20
>> @runpaint I don't think it does, since comment 17 does a simple =
require without requiring
>> rubygems or using the #gem command.
>=20
> I misspoke. I meant that if it is preceded with `require 'rubygems'` =
it works as it should. IOW, the 1.8, and arguably correct, behaviour is =
available by explicitly requiring 'rubygems', meaning that scripts that =
work under 1.8 will behave in the same fashion under 1.9. Under 1.9, =
fans of brevity can omit `require 'rubygems'` if willing to accept the =
altered semantics. This is an uneasy compromise from any angle, but does =
at least retain backward compatibility.

I don't agree, this is forcing people to add require 'rubygems' to their =
code, which is unacceptable as well. Introducing broken semantics into =
the core language will add support load to rubygems, bundler, debian, =
rails, and a bunch of other places. This is totally unfair in light of =
it basically being a poor approach at optimisation-by-replacement rather =
than optimisation by profiling and fixing the core problems. See my =
optimisations of rubygems (which at the moment the most significant =
impact is a hack to allow not loading plugins). There is more than can =
be done in this direction, and in my opinion gem_prelude should never =
have been created instead of doing these optimisations on core. To =
completely violate semantics and pass issues frequently down to users, =
and to suggest that they should then fix these issues by invoking bad =
practices is totally ridiculous, I really can't bring myself to respond =
to this kind of comment more lightly.

The situation is unacceptable, and its continuation is irresponsible.

> ----------------------------------------
> http://redmine.ruby-lang.org/issues/show/3140
>=20
> ----------------------------------------
> http://redmine.ruby-lang.org
>=20