> 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 [EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )