From: "Haase, Konstantin" Date: 2010-12-02T21:33:54+09:00 Subject: [ruby-core:33518] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods On Dec 2, 2010, at 12:30 , Shugo Maeda wrote: > 2010/11/27 Haase, Konstantin : >> So, is local rebinding still on the table? From my point of view local rebinding is far more intuitive and there are some use cases I am not sure I could solve without local rebinding. > > Could you tell me one of the use cases? When writing an asynchronous Rack application, you cannot use Rack::Lint, since you return a status code of -1 to signal your Rack handler that you will 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 monkey-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 == -1 end end end using AsyncRack The complete async rack library (https://github.com/rkh/async-rack) could be implemented that way. Evil hacks for replacing constants are necessary at the moment, though it would also be solvable - modulo having the changes only locally instead of globally - by the proposed Module#prepend. I think in general there are two rather distinct use case groups: Those where I don't know and don't want to have to care about the internals of the class 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 class names are mapped to files only in one initializer). If I don't have local rebinding, I would still have to care about the original implementation in 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