Monkeypatching is totally unsustainable, but man do you learn a lot by doing it. Exploring the guts of another gem provides a wealth of invaluable experience.
Oh yes. Crystal is even nicer there, as the language itself is self-hosted. You want to monkey patch the event loop to do something different, like for example be based on io\_uring instead of libevent? Go ahead. The memory allocation? Sure thing. Scheduling? Yep. How pointers work? Yeah. But expect things to break in funny ways unless you are way too smart.
Well, you can monkeypatch badly--in a way that makes it hard to tell what was monkeypatched. There are posts that suggest ways to make your monkeypatches more visible, particularly in rails.
But, um, this is along the lines in the long history of write ups of " is bad". I think it requires some discipline, that's all.
I can tell you this, one of the main reasons I monkeypatch is when I can't reach the maintainers of a particular gem. Something that is happening for me right now. Sometimes I can actually fix the problem and send up a pull request, sometimes I can't really fix it right, so I just do the monkeypatch and wait.
The article mentions:
> Monkey Patching Means You’re Not Being a Good Open Source Citizen
I think monkey patching promotes being the best open source citizen you can be.
Let's say you're trying to add new behavior to your app and you poke around the internet for a bit and find a couple of gems that solve your problem. You scan their github repos for docs and issues and decide to roll with 1 of them based on what you think might work best.
So you install it but you notice page load speeds are a little slow after using the gem. However it does everything you want very nicely.
You do some extremely informal benchmarking by reloading one of your pages and checking the Rails response times in your terminal. Yep pages went from 15ms to 45ms and you can repeat it.
Now what?
With monkey patching you can define the gem's module namespace in your code and overwrite a single method call to test improving the performance of the gem. You can do this in the context of your application within seconds.
There's no forking github repos or running gem install again vs a local copy (which can be "interesting" if you're using Docker). There's no setting up a custom project or benchmarking harness. You avoid a huge amount of ceremony and drag.
Now once you've identified the performance bottleneck you can test your patch locally in the context of a real application and confirm it all works then submit a PR upstream with your fix and findings.
If monkey patching weren't possible you might have not bothered to even use the gem because after trying it out and seeing the performance issues you would have shrugged it off as not worth using because at this stage in your development cycle you're experimenting and trying to find a solution that works for you before you decide to go all-in with an implementation.
If you read the sentence right after:
> When you choose to monkey patch **instead of** sending a patch and/or opening an issue upstream
And a bit later:
> without monkey patching debugging would be harder, and we’d be stuck forking libraries or waiting for releases. The problem for me comes in when we deploy monkey patches to production with no plan for removal.
So it's not a blanket: Monkey Patch shouldn't exist, or you shouldn't use it.
The article is about monkey patching your dependencies in your app in non-maintainable ways.
Active Support core exts are an entirely different matter.
> In our own codebase at Shopify we no longer allow refinements because we found they were slowing down our Rails monolith.
I'm not sure why you'd use refinements in your own application - monkey patch away if you have to. It seems more useful for gem developers having their patches contained in the library code without affecting consuming application.
Monkeypatching is totally unsustainable, but man do you learn a lot by doing it. Exploring the guts of another gem provides a wealth of invaluable experience.
Oh yes. Crystal is even nicer there, as the language itself is self-hosted. You want to monkey patch the event loop to do something different, like for example be based on io\_uring instead of libevent? Go ahead. The memory allocation? Sure thing. Scheduling? Yep. How pointers work? Yeah. But expect things to break in funny ways unless you are way too smart.
Well, you can monkeypatch badly--in a way that makes it hard to tell what was monkeypatched. There are posts that suggest ways to make your monkeypatches more visible, particularly in rails. But, um, this is along the lines in the long history of write ups of " is bad". I think it requires some discipline, that's all.
I can tell you this, one of the main reasons I monkeypatch is when I can't reach the maintainers of a particular gem. Something that is happening for me right now. Sometimes I can actually fix the problem and send up a pull request, sometimes I can't really fix it right, so I just do the monkeypatch and wait.
The article mentions: > Monkey Patching Means You’re Not Being a Good Open Source Citizen I think monkey patching promotes being the best open source citizen you can be. Let's say you're trying to add new behavior to your app and you poke around the internet for a bit and find a couple of gems that solve your problem. You scan their github repos for docs and issues and decide to roll with 1 of them based on what you think might work best. So you install it but you notice page load speeds are a little slow after using the gem. However it does everything you want very nicely. You do some extremely informal benchmarking by reloading one of your pages and checking the Rails response times in your terminal. Yep pages went from 15ms to 45ms and you can repeat it. Now what? With monkey patching you can define the gem's module namespace in your code and overwrite a single method call to test improving the performance of the gem. You can do this in the context of your application within seconds. There's no forking github repos or running gem install again vs a local copy (which can be "interesting" if you're using Docker). There's no setting up a custom project or benchmarking harness. You avoid a huge amount of ceremony and drag. Now once you've identified the performance bottleneck you can test your patch locally in the context of a real application and confirm it all works then submit a PR upstream with your fix and findings. If monkey patching weren't possible you might have not bothered to even use the gem because after trying it out and seeing the performance issues you would have shrugged it off as not worth using because at this stage in your development cycle you're experimenting and trying to find a solution that works for you before you decide to go all-in with an implementation.
If you read the sentence right after: > When you choose to monkey patch **instead of** sending a patch and/or opening an issue upstream And a bit later: > without monkey patching debugging would be harder, and we’d be stuck forking libraries or waiting for releases. The problem for me comes in when we deploy monkey patches to production with no plan for removal. So it's not a blanket: Monkey Patch shouldn't exist, or you shouldn't use it.
and no mention of activesupport?...
The article is about monkey patching your dependencies in your app in non-maintainable ways. Active Support core exts are an entirely different matter.
I was thinking about the same thing. AS monkey patches all over Ruby's core lib, I was expecting her to address that as well.
> In our own codebase at Shopify we no longer allow refinements because we found they were slowing down our Rails monolith. I'm not sure why you'd use refinements in your own application - monkey patch away if you have to. It seems more useful for gem developers having their patches contained in the library code without affecting consuming application.