[Zope-dev] A Modest Proposal Concerning Monkey Patches

Casey Duncan casey@zope.com
Tue, 13 Aug 2002 14:33:57 -0400


On Tuesday 13 August 2002 02:10 pm, jlagarde@bigfoot.com wrote:
> On Tue Aug 13, 2002, Jim Penny wrote:
> > There is a large problem looming with Moneky Patches. The problem is
> > that monkey patches are so Highlander. "There can be Only One".
> >=20
> > For example, there are at least five or six products that monkey patc=
h
> > manage_main. Each simply replaces whatever manage_main exists at the
> > time of instantation, and blows away any previous monkey patch. Some
> > coordinated way of dealing with this problem needs to be arrived at.
> >
>=20
> And if you upgrade Zope, the patched version of manage_main will discar=
d
> any changes made in the new version of Zope.

That is why it would be beneficial to make the thing being patched extens=
ible=20
in the first place thereby alleviating the need to patch it.

> > Proposal:
> [ideas on how to check for previous changes and what to do about it]
>=20
> Here is a more surgical option for small changes: Instead of
> indiscriminately replacing the whole function or method, decompile and
> look for and replace only that part of the code that you want to change=
=2E
> In that way, as long as that part of the code remains valid between
> versions, the change probably remains valid, and you apply it. If you
> can't find the part of the code that you want to change, then some othe=
r
> change you are not aware of happened, so do not apply your change. I us=
e
> decompyle and re to do the work. Here is an example:

[snip example]

I thought about an approach like this, but I think it is susceptible to s=
ubtle=20
bugs. It is very hard to predict the interaction of products independentl=
y=20
changing the same template. As a product author, trying to support such a=
=20
thing is not very attractive.

I would prefer to make the template itself more flexible then try to jam =
new=20
code into it sideways at run-time.

-Casey