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

[Brian Lloyd]

> Indeed.  However, I was being a bit glib with my example, and didn't
> explain my point properly: that performance issues should be subordinate
> to good design.  Therefore, I suspect MonkeyPatching is bad:
> 
>  Pros - a tiny performance gain
>  Cons - unpredictable interaction with future products; not a well-known
> method of distributing products; not easily discoverable
> 
> But perhaps my 'cons' are misplaced?  Mostly, I'm uneasy that someone
> looking at ZPublisher code would have no way of knowing that
> CallProfiler hooks into it if it were monkeypatched.

Monkey-patching should be thought of as a last resort, when it 
absolutely-positively-has-to-get-there-overnight (security hotfixes, 
etc.), for exactly the cons described above. Speaking as one who 
has been bitten by this sort of thing before (with the bite marks
to prove it!), I can attest that the only thing worse than confusing 
code is _invisible_ code.

That said -- I think that Richard's approach is quite powerful, and 
I think that there is a middle ground here. I think that the call 
profiler could be brought into the core with minimal changes and 
without being "invisible" or seeming to promote monkey-patching.

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. 

Think of this as "consentual" monkey-patching (hmm... may have to 
change this metaphor soon!). The products have to take some explicit 
action to be profilable, so it is not invisible in the code of the 
product. The hooks will continue to installed as-needed, so there 
is no performance issue.

Thoughts?


Brian Lloyd        brian@zope.com
Software Engineer  540.361.1716       
Zope Corporation   http://www.zope.com