On Dec 2, 2010, at 12:30 , Shugo Maeda wrote:

> 2010/11/27 Haase, Konstantin <Konstantin.Haase / student.hpi.uni-potsdam.de=
>:
>> So, is local rebinding still on the table? From my point of view local r=
ebinding is far more intuitive and there are some use cases I am not sure I=
 could solve without local rebinding.
>=20
> Could you tell me one of the use cases?

When writing an asynchronous Rack application, you cannot use Rack::Lint, s=
ince you return a status code of -1 to signal your Rack handler that you wi=
ll respond to the incoming request later. One option would be to completely=
 disable Rack::Lint, which might not be what you want and is a bit painful,=
 as it is hardcoded to be used in development mode in Rack. One could monke=
y-patch Rack::Lint directly, but it would be even better if it only excepts=
 -1 for your application:

	module AsyncRack
		refine Rack::Lint do
			def check_status(status)
				super unless status =3D=3D -1
			end
		end
	end

	using AsyncRack

The complete async rack library (https://github.com/rkh/async-rack) could b=
e implemented that way. Evil hacks for replacing constants are necessary at=
 the moment, though it would also be solvable - modulo having the changes o=
nly locally instead of globally - by the proposed Module#prepend.

I think in general there are two rather distinct use case groups: Those whe=
re I don't know and don't want to have to care about the internals of the c=
lass that's being refined and those where I do and explicitly want to reach=
 in deep to change a single internal (say in Rails I want to change how cla=
ss names are mapped to files only in one initializer). If I don't have loca=
l rebinding, I would still have to care about the original implementation i=
n order to figure out what methods are calling the method I want to change.=
 In the Enumerable example I would have to override about every method, not=
 only each, in order to change the behavior consistently.

Konstantin=