>>> Now plug and play comes into play:
>>> Assume two packages developped by independent people
>>> which all want to control the order of hook execution.
>> Do we have evidence that such applications exist? So far, the only
>> example I've seen is one where an application wanted a handler to go
>> last. As I've pointed out in a separate note, this is achievable without
>> the change.
> I have a *package* (similar to Archetypes SQLStorage) that wants to go
> after everything that might possibly change attributes whether those
> changes are done by another component from me or any package developped
> by someone else.
Dieter, how does order= solve that for you? There is no value you can pass
to guarantee your hook will run last.
As Jim said earlier (albeit obliquely), with the old method you could
guarantee that your hook ran after all hooks registered by the time a commit
began, via registering a hook H1 any old time, where H1's only action when
called is to register a new hook H2. The old method guaranteed to call
hooks in registration order, so it was guaranteed that H2 wouldn't be called
until after all the hooks that were registered at the time the commit began
That wouldn't guarantee H2 ran last either, but neither can order=.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org