[Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)

Richard Jones rjones@ekit-inc.com
Tue, 5 Mar 2002 10:42:42 +1100


On Tue, 5 Mar 2002 07:20, Brian Lloyd wrote:
> Seb wrote:
> >  Pros - a tiny performance gain
> >  Cons - unpredictable interaction with future products; not a well-known
> > method of distributing products; not easily discoverable
>
> What if, instead of the static list of callable info that the CP
> currently uses, Zope objects could register themselves as profilable?
> We would then make sure that the object types that CP handles now
> register themselves, but other products that we don't know (or
> have to know) about could register themselves too if they wanted.

This doesn't really address the concern I have with regard to the con given 
above. The main reason is that the call profiler's monkeypatching is done 
potentially many times, and it performs an unpatch as well as a patch. This 
muckery can potentially really stuff over other components that also 
monkeypatch the same methods. Especially if they _also_ perform unpatching.

I'm not sure the consentual monkeypatch approach really solves this issue... 
and if the product has to be modified to make it register itself with the 
profiler, why not just have it include the (very simple) calls to the 
profiler instead?


    Richard