4 ms·

I have mixed feelings about this. It's good because you gain an ability to scope your monkey patches. It's bad because it incentivizes monkey-patches.

generalk 16y ago
I don't get it. What's bad about incentivizing monkey-patches that don't interfere with other code?
- jonathanwallace 16y ago
  The only thing that comes to mind is its not immediately obvious when source diving when a piece of code has been refined or redefined. IMO, this is the justified cost of flexibility provided by monkey-patching.
  - djacobs 16y ago
    Agreed. Especially if there's no other (clean) option to accomplish what you want. As always, lucid comments are vital for high-level code.
  - jerf 16y ago
    This isn't specifically a problem with monkeypatching. Not knowing what is in scope right now is a generalized problem with object oriented programming. Scoped monkeypatches doesn't really add to the problem, IMHO. (Please note I don't even mean that as a criticism of OO per se. Like everything else, it has costs and benefits, and that is, well, actually a bit of both. Things being hidden from you is annoying, but if you switch to something like Haskell you'll find that everything being shown isn't always entirely cool either.)
ericb 16y ago
In many other languages it is agonizing to see a solution that does 95% of what you want. Without that last 5% it is unusable for your purposes and you are forced to reinvent a wheel. As dangerous as they are, there is a reason people monkey patch. Refinements will just help remove the downsides.
jerf 16y ago
The badness of monkeypatching is its ability to make non-local changes that stomp on other code. Monkeypatches aren't bad in a general sense. Take away the stomping behavior and you've taken away the badness. (They might still be "dangerous" but you've moved them out of the "suicidal" territory I believe non-scoped monkeypatches live in.) Incidentally, Perl has been able to do this for a long time. I've gotten a lot of mileage out of: local *{'Some::Module::method'} = sub { ... }; my $thing = new Some::Module(); ... $thing->method(...); ... It's great for testing, great for modifying the way libraries work locally without globally modifying them (in my case, hacking a bit on code shared by many projects in such a way that I can't really add this thing I really need), and so on. A great addition to Ruby that goes a long way towards mitigating some of my fundamental complaints about the language.

generalk 16y ago

I don't get it. What's bad about incentivizing monkey-patches that don't interfere with other code?

jonathanwallace 16y ago
The only thing that comes to mind is its not immediately obvious when source diving when a piece of code has been refined or redefined. IMO, this is the justified cost of flexibility provided by monkey-patching.
- djacobs 16y ago
  Agreed. Especially if there's no other (clean) option to accomplish what you want. As always, lucid comments are vital for high-level code.
- jerf 16y ago
  This isn't specifically a problem with monkeypatching. Not knowing what is in scope right now is a generalized problem with object oriented programming. Scoped monkeypatches doesn't really add to the problem, IMHO. (Please note I don't even mean that as a criticism of OO per se. Like everything else, it has costs and benefits, and that is, well, actually a bit of both. Things being hidden from you is annoying, but if you switch to something like Haskell you'll find that everything being shown isn't always entirely cool either.)

ericb 16y ago

In many other languages it is agonizing to see a solution that does 95% of what you want. Without that last 5% it is unusable for your purposes and you are forced to reinvent a wheel. As dangerous as they are, there is a reason people monkey patch. Refinements will just help remove the downsides.

jerf 16y ago

The badness of monkeypatching is its ability to make non-local changes that stomp on other code. Monkeypatches aren't bad in a general sense. Take away the stomping behavior and you've taken away the badness. (They might still be "dangerous" but you've moved them out of the "suicidal" territory I believe non-scoped monkeypatches live in.) Incidentally, Perl has been able to do this for a long time. I've gotten a lot of mileage out of: local *{'Some::Module::method'} = sub { ... }; my $thing = new Some::Module(); ... $thing->method(...); ... It's great for testing, great for modifying the way libraries work locally without globally modifying them (in my case, hacking a bit on code shared by many projects in such a way that I can't really add this thing I really need), and so on. A great addition to Ruby that goes a long way towards mitigating some of my fundamental complaints about the language.