[Zope3-dev] Subscriber Depencies

[Ross Patterson]

It would be very useful to establish dependencies between subscriber
registrations which would be used to determine the order in which the
subscriber factories or handlers are called and resutls returned.

We'll need the following in our examples::

    >>> foo = []
    >>> def handleFoo(context): foo.append(context)

    >>> from zope.interface import Interface, implements
    >>> class IFoo(Interface): pass

    >>> class Foo(object): implements(IFoo)

    >>> class IBar(Interface): pass

Given that duplicate factories/hanlders could have indeterminate
effects, it would be ideal to be able to uniquely identify a
registration in order to define dependencies.  Unfortunately, an
identiical subscriber registration can be duplicated::

    >>> from zope.component import provideSubscriptionAdapter
    >>> provideSubscriptionAdapter(
    ...     adapts=[IFoo],provides=IBar, factory=handleFoo)
    >>> provideSubscriptionAdapter(
    ...     adapts=[IFoo],provides=IBar, factory=handleFoo)

    >>> from zope.component import subscribers
    >>> [i for i in subscribers([Foo()], IBar)]
    []
    >>> foo
    [<Foo object at ...>, <Foo object at ...>]

As such, we can't use the registration triad to uniquely identify
registrations.  From a quick session with pdb, it doesn't appear that
any other identifying information is stored with the registration, nor
is any unique object created during registration that might be used to
distinguish between duplicate registrations.

There is currently no way to specify between duplicate registrations
for subscriber dependencies.

There may be a way to create a unique identifier when registration
occurs, but how would it be selected in code specifying dependencies?
The duplicate subscribers may be registered in the same package or
module.  Identifying them by indexes in a sequence of duplicates may
be possible but seems kludgy at best espeically when you occur the
number of ways that registrations can occur: modules, ZCML, running
code that registers persistent subscribers that have no module, etc..

Since this would just be a dependency system, it may be sufficient to
define dependencies between differing/non-duplicate registrations.  I
could start an implementation if it would be useful.

Ross