Monkey Patching in Go

This is awful, dangerous, and compiler designers and writers will yell at you. Well done :)<p>I&#x27;ve always wanted a way to monkey-patch otherwise statically and well-bound code, but only for testing. In C, it&#x27;s fairly easy to set up preprocessor rules to do so, though also litters your primary code with test specific stuff. I have mostly focused on how to integrate this into compiler logic; Building some functionality to replace specified symbols in the build phase. Simply replacing the function pointers in the runtime is brilliant, if more than a little hacky and prone to problems.<p>I look forward to playing around with this.

This is not monkey patching. This is the good old function&#x2F;api &quot;hooking&quot; that&#x27;s pretty common in the compiled language world: <a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hooking" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hooking</a><p>Monkey patching is a less invasive version of hooking used in dynamic languages. Bottom line: if you are dealing with assembly it&#x27;s no longer monkey patching :-)

This does not work for any non-trivial function because of missing stack map for the GC and stack copier.

So, this is a step towards implementing plugins for go right? It seems to me like this could be used to implement dynamic code loading.

This is admirable work in the pursuit of evil.

Could this be expanded to hot-swap code as you write it?

Is this safe for such short functions? What if the patch takes more space than the original code?