--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 09, 2011 at 01:04:08AM +0900, Antonio Terceiro wrote:
> When there is both foo.rb and foo.so and a `require 'foo'` call is evalua=
ted, Ruby 1.8 will load either foo.rb or foo.so depending on which order th=
eir directories are in $LOAD_PATH.
>=20
> Ruby 1.8 will load the first foo.rb or foo.so it finds in the $LOAD_PATH.
>=20
> Ruby 1.9 will first look for foo.rb in all directories, and only after th=
at it will look for foo.so in all directories. This behaviour seems more co=
nsistent than the one in Ruby 1.8. It also matches the most common use case=
, which is foo.rb loading its sister foo.so that contains native-code imple=
mentations needed by foo.rb.
>=20
> I have attached a test case that shows these different behaviours of Ruby=
 1.8 and Ruby 1.9.
>=20
> I propose to make Ruby 1.8 work the same way as Ruby 1.9. If there is con=
sensus about that, I can try to write a patch to backport the behaviour of =
Ruby 1.9 for Ruby 1.8.

Making this change would break 1.8 users that depend on this behavior.
Users may *unknowingly* depend on this behavior.  Imagine someone's pain
that makes what *seems* like a safe upgrade (say 1.8.7-p1 to 1.8.7-p2),
and boom, my application stops working because of require behavior
change.

Contrast that with upgrading to 1.9, where the user *knows* some
behaviors of Ruby may have changed.

This isn't a bug, it's a behavior.  Leave 1.8 as is.  Let users upgrade to =
1.9.

--=20
Aaron Patterson
http://tenderlovemaking.com/

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJOF0EdAAoJEJUxcLy0/6/GggMH/ihGRzVQtk5GGNxMlsEd7O0n
WtOIFvXLUSZlAfYLdNsUcwdvCwg/qF2rIqpzuQi6cnCoaRbxqsHYtv8C0wXnBaGh
omDci3QVcBZTv2J9awLJrCfI0Gan75w/1U1pbZWTFALZ7PECnlon6vLRaRVoGV8p
NiIYJ0VOIzd/ll/QBPxXr6MByUg+5Li1BgIARuLWK2FBLNBVSaz6OQFhqu2sJvxJ
jZLg/V9VnkksuWS9kTz/tuHccikCBmSryfj3wdawwSFp/jDBnS8J9NLvW3l4d4qW
mQdKG9A5JWag8a305xFejN1CAPsU/x7vdBSCphLSUnMZauB3ZksdqSkwSUmk0t0=
=zgdq
-----END PGP SIGNATURE-----

--sdtB3X0nJg68CQEu--

On Sat, Jul 09, 2011 at 01:04:08AM +0900, Antonio Terceiro wrote:
> When there is both foo.rb and foo.so and a `require 'foo'` call is evalua=
ted, Ruby 1.8 will load either foo.rb or foo.so depending on which order th=
eir directories are in $LOAD_PATH.
>=20
> Ruby 1.8 will load the first foo.rb or foo.so it finds in the $LOAD_PATH.
>=20
> Ruby 1.9 will first look for foo.rb in all directories, and only after th=
at it will look for foo.so in all directories. This behaviour seems more co=
nsistent than the one in Ruby 1.8. It also matches the most common use case=
, which is foo.rb loading its sister foo.so that contains native-code imple=
mentations needed by foo.rb.
>=20
> I have attached a test case that shows these different behaviours of Ruby=
 1.8 and Ruby 1.9.
>=20
> I propose to make Ruby 1.8 work the same way as Ruby 1.9. If there is con=
sensus about that, I can try to write a patch to backport the behaviour of =
Ruby 1.9 for Ruby 1.8.

Making this change would break 1.8 users that depend on this behavior.
Users may *unknowingly* depend on this behavior.  Imagine someone's pain
that makes what *seems* like a safe upgrade (say 1.8.7-p1 to 1.8.7-p2),
and boom, my application stops working because of require behavior
change.

Contrast that with upgrading to 1.9, where the user *knows* some
behaviors of Ruby may have changed.

This isn't a bug, it's a behavior.  Leave 1.8 as is.  Let users upgrade to =
1.9.

--=20
Aaron Patterson
http://tenderlovemaking.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJOF0EdAAoJEJUxcLy0/6/GggMH/ihGRzVQtk5GGNxMlsEd7O0n
WtOIFvXLUSZlAfYLdNsUcwdvCwg/qF2rIqpzuQi6cnCoaRbxqsHYtv8C0wXnBaGh
omDci3QVcBZTv2J9awLJrCfI0Gan75w/1U1pbZWTFALZ7PECnlon6vLRaRVoGV8p
NiIYJ0VOIzd/ll/QBPxXr6MByUg+5Li1BgIARuLWK2FBLNBVSaz6OQFhqu2sJvxJ
jZLg/V9VnkksuWS9kTz/tuHccikCBmSryfj3wdawwSFp/jDBnS8J9NLvW3l4d4qW
mQdKG9A5JWag8a305xFejN1CAPsU/x7vdBSCphLSUnMZauB3ZksdqSkwSUmk0t0=
=zgdq
-----END PGP SIGNATURE-----