[Zope3-dev] Re: hook and hookable zcml

[Gary Poster]

R. David Murray wrote:
> Gary Poster wrote:
> > hook and hookable are ways of setting up explicit monkey patches:
you
> > declare that something can be monkey patched with "hookable", and
make a
> > replacement for it with "hook".  You can't hook anything that isn't
> > declared as hookable, and you can't hook the same hookable twice.
It
> > also gives you a registry which could theoretically give information
TTW
> > (read-only) on what has been monkey-patched via the hookable/hook
> mechanism.
> >
> > So, keep and fix, or trash and regroup?
> 
> Since it doesn't really solve the problem (multiple safe monkey
> patches), and isn't yet really used, I'd vote for ripping it out
> for the Alpha and redesigning it after. 

That sounds fine to me, but then I need a consensus or Papal decree on
how to replace it in its one use.

lib/python/Zope/ComponentArchitecture/__init__.py is the file that has a
hookable right now--getServiceManager can't know about placeful stuff in
Zope/ComponentArchitecture (because it is outside of App) but we import
all of the basic Component Architecture tools from
Zope/ComponentArchitecture, so it has to be placeful when Zope code uses
it.  getServiceManager is the key stone from which the other CA
functions get their placeful behavior.  Currently
Zope/App/ComponentArchitecture/ provides the hook.

The easy-but-time-consuming solution seems to me to be to have the
Component Architecture functions duplicated placefully in
Zope/App/ComponentArchitecture and then have all Zope code import
Component Architecture stuff from Zope.App.ComponentArchitecture instead
of Zope.ComponentArchitecture.  That might be risky, because you could
still import from Zope.ComponentArchitecture and it would seem to work,
but it is a solution that has parallels with other refactoring being
done now.

If we don't have a good answer to this then I'd prefer to leave things
as they are.

---

For discussion and understanding of the future "right" solution for
monkey-patching, how does the hook/hookable mechanism not solve the
problem of multiple monkey patches?  It does disallow hooking the same
code more than once, which I regard as a feature, not a flaw.

> Besides, I thought we were trying to avoid the need for
> monkey patching <grin>.

Agreed.  I'd be surprised if it disappeared entirely, though.

Gary