This patch refactors zend-eventmanager with the following goals:

• Maintainability.
  • It removes methods where they have no clear purpose or are redundant.
  • It simplifies signatures where arguments have multiple possible types or meanings; if necessary, it creates new methods when multiple signatures are deemed useful.
• Performance.
  • Queues are inlined into the implementations whenever possible to promote performance.
  • Arrays are preferred over objects for queues due to the speed of array manipulation in PHP.
  • Features such as lazy listeners were added to help users further optimize their event manager usage.
  • A benchmarking suite using Athletic was written to help gauge the differences between versions and approaches.
• Usability.
  • Whenever possible, signatures were refactored to have a single set of valid arguments, and a single execution path, providing reliability and easing the ability to learn usage.
  • Documentation was written alongside the implementation to aid in identifying difficult and redundant usage areas.

Alongside these goals, we also tried to minimize migration for end users. To this end, migration document was written, and a 2.6.0 release is planned in order to deprecate methods as well as add implementation methods to the EventManager that will aid in helping users prepare their code for version 3.

Listeners are executed exactly as they were in version 2, using the same priorities and precedence between local explicit and wildcard listeners, and shared and shared wildcard listeners. Tests were added to describe and document these rules.

Change synopsis

Removed functionality

• GlobalEventManager and StaticEventManager are removed (with prejudice!).
• ProvidesEvents, which was previously deprecated, is removed.
• EventManagerInterface::setSharedManager() is removed. Shared managers are now expected to be injected during instantiation.
• EventManagerInterface::getEvents() and getListeners() are removed; they had now purpose within the implementation.
• EventManagerInterface::setEventClass() was renamed to setEventPrototype(), which now expects an EventInterface instance. That instance will be cloned whenever a new event is created.
• EventManagerInterface::attachAggregate() and detachAggregate() are removed. Users should use the attach() and detach() methods of the aggregates themselves.
• SharedEventAggregateAwareInterface and SharedListenerAggregateInterface are removed. This was an undocumented and largely unused feature.
• SharedEventManagerAwareInterface is removed. A new interface, SharedEventsCapableInterface defines the getSharedManager() method from the interface, and EventManagerInterface extends that new interface.
• SharedEventManagerInterface::getEvents() is removed, as it had no purpose in the implementation.

Changed signatures

• EventManager::__construct() now accepts an optional SharedEventManagerInterface instance as the first argument, and an optional array of identifiers as the second. As identifiers have no meaning without a shared manager present, they are secondary to providing the shared manager.
• EventManagerInterface::trigger() changes its signature to trigger($eventName, $target = null, $argv = []); each argument has exactly one possible meaning; the $eventName can only be a string event name. The fourth $callback argument is removed.
• EventManagerInterface::triggerUntil() changes its signature to triggerUntil(callable $callback, $eventName, $target = null, $argv = null). Each argument has exactly one meaning.
• EventManagerInterface adds two new methods for triggering provided EventInterface arguments: triggerEvent(EventInterface $event) and triggerEventUntil(callable $callback, EventInterface $event).
• EventManagerInterface::attach() and detach() change their signatures to attach($eventName, callable $listener, $priority = 1) and detach(callable $listener, $eventName = null), respectively. Note that $eventName can now only be a string event name, not an array or Traversable.
• EventManagerInterface::setIdentifiers() and addIdentifiers() change their signatures to each only accept an array of identifiers.
• SharedEventManagerInterface::getListeners() changes signature to getListeners(array $identifiers, $eventName) and now guarantees return of an array. Note that the second argument is now required.
• SharedEventManagerInterface::attach() changes signature to attach($identifier, $eventName, callable $listener, $priority = 1). The $identifier and $eventName must be strings.
• SharedEventManagerInterface::detach() changes signature to detach(callable $listener, $identifier = null, $eventName = null); $identifier and $eventName must be strings if passed.
• ListenerAggregateInterface::attach() adds an optional $priority = 1 argument. This was used already in v2, but not dictated by the interface.
• FilterInterface::attach() and detach() have changed signature to attach(callable $callback) and detach(callable $ilter), respectively.
• FilterIterator::insert() has been modified to raise an exception if the value provided is not a callable.
• ResponseCollection::setStopped() no longer implements a fluent interface.

New functionality

• LazyListener allows wrapping:
  • fetching a listener service from a container-interop container, and
  • invoking a designated listener method with the provided event.
• LazyEventListener extends LazyListener, and provides metadata for discovering the intended event name and priority at which to attach the lazy listener; these are consumed by:
• LazyListenerAggregate, which, provided a list of LazyEventListeners and/or definitions to use to create them, acts as an aggregate for attaching a number of such listeners at once.

Benchmarks

Benchmarks are listed in a gist. In particular:

• benchmark of version 2
• benchmark of final version of this implementation

The highlight is the MultipleEventMultipleLocalAndSharedListener benchmark, which demonstrates a real-world usage scenario in zend-mvc with many local and shared listeners, and many events being triggered. This benchmark jumped from 435 operations per second in version 2 to 1265 operations per second in this implementation — a change of ~300%! Considering this represents 10–50X the number of events triggered in a reasonably sized zend-mvc application, performance will be in the sub-millisecond range.

After my PR #16 I experimented with integer priorities.

It's no longer storing priorities as string with .0 suffix but store as integer. This makes it harder to merge listeners of the same priority by name, wildcard or shared but in the end I sow a very good performance improvement, only MultipleEventMultipleSharedListener decreases a little (see below).

All tests passed for me but it should be tested carefully anyway ;)

PHP 5.6

PHP 5.6.14-0+deb8u1 (cli) (built: Oct 4 2015 16:13:10) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

Branch: develop

ZendBench\EventManager\MultipleEventIndividualSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000237437248] [42,116.39107]


ZendBench\EventManager\MultipleEventLocalListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000196894646] [50,788.58272]


ZendBench\EventManager\MultipleEventMultipleLocalAndSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0002710880280] [3,688.83867]


ZendBench\EventManager\MultipleEventMultipleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000575615883] [17,372.69644]


ZendBench\EventManager\SingleEventMultipleListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000446063042] [22,418.35585]


ZendBench\EventManager\SingleEventMultipleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000478469849] [20,899.95854]


ZendBench\EventManager\SingleEventSingleListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000078002930] [128,200.31299]


ZendBench\EventManager\SingleEventSingleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000106687546] [93,731.65281]

Branch: integer_priority

ZendBench\EventManager\MultipleEventIndividualSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000230637074] [43,358.16375]


ZendBench\EventManager\MultipleEventLocalListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000166062355] [60,218.34387]


ZendBench\EventManager\MultipleEventMultipleLocalAndSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0002452962399] [4,076.70334]


ZendBench\EventManager\MultipleEventMultipleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000640497684] [15,612.85894]


ZendBench\EventManager\SingleEventMultipleListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000399168015] [25,052.10747]


ZendBench\EventManager\SingleEventMultipleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000434321880] [23,024.39838]


ZendBench\EventManager\SingleEventSingleListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000066055775] [151,387.21856]


ZendBench\EventManager\SingleEventSingleSharedListener
    Method Name   Iterations    Average Time      Ops/second
    -------  ------------  --------------    -------------
    trigger: [5,000     ] [0.0000096778870] [103,328.34056]

PHP 7.0

PHP 7.0.0 (cli) (built: Dec 5 2015 23:50:11) ( NTS ) Copyright (c) 1997-2015 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2015 Zend Technologies

Fatal error: Uncaught TypeError: Argument 1 passed to Athletic\Common\CmdLineErrorHandler::handleException() must be an instance of Exception, instance of Error given in /home/mabe/workspace/zend-eventmanager/vendor/athletic/athletic/src/Athletic/Common/CmdLineErrorHandler.php:35
Stack trace:
#0 [internal function]: Athletic\Common\CmdLineErrorHandler->handleException(Object(Error))
#1 {main}
  thrown in /home/mabe/workspace/zend-eventmanager/vendor/athletic/athletic/src/Athletic/Common/CmdLineErrorHandler.php on line 35

Something with athletic doesn't work with PHP-7 but I have no time to figure that out.

Hi everyone,

PS: Everyone is free to fork my branch and submit PR to it!

Motivation

Event manager has always been, with service manager, the slowest parts of ZF2, but the most widely used one internally. It was therefore highly important to make them faster.

Also, the event manager was a complex piece of software with a lot of obscure features, a strange shared manager concept and complex signatures.

Breaking changes

Massive performance improvements

I copy-paste some of the benchmarks I've made (the PHP7 build was an old one, so expect at least 10-15% improvments on PHP7):

ZF2 EVM

PHP 5.6

Bench\EventManagerBenchmark
Method Name          Iterations    Average Time      Ops/second
------------------  ------------  --------------    -------------
attach20Listeners : [1,000     ] [0.0005693485737] [1,756.39326]
trigger20Listeners: [1,000     ] [0.0010452888012] [956.67341]

PHP 7

Bench\EventManagerBenchmark
Method Name          Iterations    Average Time      Ops/second
------------------  ------------  --------------    -------------
attach20Listeners : [1,000     ] [0.0000875046253] [11,427.96734]
trigger20Listeners: [1,000     ] [0.0001518340111] [6,586.13965]

ZF3 EVM

PHP 5.6

Bench\EventManagerBenchmark
Method Name          Iterations    Average Time      Ops/second
------------------  ------------  --------------    -------------
attach20Listeners : [1,000     ] [0.0001252155304] [7,986.22980]
trigger20Listeners: [1,000     ] [0.0002773256302] [3,605.86939]

PHP 7

Bench\EventManagerBenchmark
Method Name          Iterations    Average Time      Ops/second
------------------  ------------  --------------    -------------
attach20Listeners : [1,000     ] [0.0000128707886] [77,695.31713]
trigger20Listeners: [1,000     ] [0.0000429670811] [23,273.63123]

No more shared event manager

I've explain myself why I think the shared event manager was a bad idea (although @ocramius tried to show me the contrary, I think the event manager should stay simple as introduced in this PR).

As I used EVM in my app, I realized I ONLY used the Shared event manager. But the SEM is SLOW AS HELL and complex (because of identifiers, expensive merging...). I think that in most use cases, people should have a global EVM used throughout their applications, and have more precise event name.

Simplifications

Previously, trigger and triggerUntil were very complex. Depending on the order and types of parameters, you could use it in a LOT of different ways. Now everything has been enforced in interfaces, so there is one possible use case, which make things clearer and more efficient (less checks).

Event no longer has name

I've simplified the EventInterface so that it no longer has a getName method. I'm not against reverting it, but to me, we should trigger event like this:

$evm->trigger('event.name', $eventObject);

As an event object could be used for various event names, I think it makes more sense to be used like this (and avoid to re-add logic to check if the first parameter is a string or object... that kind of things).

propagationIsStopped has been renamed to isPropagationStopped.

Lazy listeners

One main issue with ZF2 was the inability to have lazy listeners. This means taht when you attach listeners, they are created, with all their dependencies, on every requests, even if you don't need them.

From my app, this can add a non-negligible overhead, and solutions like proxies are annoying to setup.

Some example usage:

<?php
    // The idea is that in ZF3, there will be one "application-wide" event manager registered. Nothing prevents you to
    // create your own local event manager, but to replicate the shared manager behaviour, you should retrieve the
    // application-wide evm

    // Attaching a simple listener:

    $eventManager = new EventManager();
    $eventManager->attach('foo', function() {}, $priority);

    // Triggering a listener
    $eventManager->trigger('foo', new Event());

    // Triggering a listener with a callable that will stop propagation if return to true
    $eventManager->triggerUntil('foo', new Event(), function() {});

    // Attaching to wildcard
    $eventManager->attach('*', function() {});

    // Attaching a listener and detaching it
    $listener = $eventManager->attach('foo', function() {});
    $eventManager->detach('foo', $listener);

    // Detaching all listeners from a given event
    $eventManager->detach('foo');


    // Using listener aggregate to aggregate multiple events, lazily
    class MyListenerAggregate implements ListenerAggregateInterface
    {
        public static function attachAggregate(EventManager $evm)
        {
            // No more confusion of getting the shared manager. Note the method is static, and
            // that we pass a "spec" without instantiating the listener, as it will be created only
            // on demand
            $evm->attach('foo', [static::class, 'myMethod']);
        }

        public function myMethod(Event $event)
        {

        }
    }

    // In the module class
    $evm = $serviceLocator->get(EventManager::class);
    MyListenerAggregate::attachAggregate($evm); // Maybe should be called "bind" instad of attachAggregate

    // No more identifiers, no more SEM... Of course, events must now be scoped, so no "created" event anymore,
    // but "user.created", "application.dispatch", "controller.dispatch"...

?>

Hey folks,

while deeply diving into event manager and its performance, I wonder if even lazier instantiation of event listeners at the last possible moment, i.e. \Zend\EventManager\EventManager::triggerListeners() could further improve performance? I realize LazyListeners already exist, but they are usually instantiated during instantiation of the respective event manager. In case of many events for the same event manager this obviously leads to many unnecessary operations.

Any opions?

Store priority as array key as "<prio>." instead of "<prio>.0" as:

• it also doesn't get converted to int
• it is a compatible float format

I have found issue in apigility https://github.com/zfcampus/zf-apigility/commit/076a21d3b81ea0ee744f73d2d40a383305a6dbb0#diff-c9248b3167fc44af085b81db2e292837R121.

My MvcEvent has stop propagation property set to true during dispatch. After this name is changed to event finish. triggerEvent method trigger my event, but after first listener stop propagation stops dispatching my event, because it's already affected by event dispatch. My proposition it's to reset always stop propagation property before trigger like here https://github.com/zendframework/zend-eventmanager/blob/release-2.6.3/src/EventManager.php#L211 . Now trigger() and triggerEvent() (or triggerEventUntil) trigger events with stop propagation = true in different way

Running my tests, I find out that ListenerAggregateInterface is not compatibile migrating from v2 to v3 due to a Fatal Error for Incompatible Interface. Seems that every listener implementing that interface should add the second parameter $priority before to migrate.

Is it right?

Per #4, we need to mark a number of features as deprecated for an upcoming 2.6.0 release. This should be done against master.

Deprecations can be done via annotations; all deprecations MUST also be noted in the CHANGELOG.md.

• [x] Mark GlobalEventManager as deprecated
• [x] Mark StaticEventManager as deprecated
• [x] Mark EventManager(Interface)?::setSharedManager as deprecated
• [x] Mark EventManager(Interface)?::getEvents as deprecated
• [x] Mark EventManager(Interface)?::getListeners as deprecated
• [x] Mark EventManager(Interface)?::setEventClass as deprecated
• [x] Mark EventManager(Interface)?::attachAggregate as deprecated
• [x] Mark EventManager(Interface)?::detachAggregate as deprecated
• [x] Mark SharedListenerAggregateInterface as deprecated
• [x] Mark SharedEventAggregateAwareInterface as deprecated
• [x] Mark SharedEventManagerAwareInterface as deprecated
• [x] Mark SharedEventManagerInterface::getEvents as deprecated
• [x] Add EventManager::triggerEvent() (but not at interface level)
• [x] Add EventManager::triggerEventUntil() (but not at interface level)

On page: https://docs.zendframework.com/zend-eventmanager/tutorial/ , there is a syntax error: $params = )'foo' => 'bar', 'baz' => 'bat']; which should be: $params = ['foo' => 'bar', 'baz' => 'bat'];

Use the FQCN of an event name make easy to provide unique event names and avoid name conflicts between libraries.

Pro:

• FQCN + PHP 5.5 class makes almost imposible mistakes in event name (typos while typing the event name string) and PHP error message is enough for to determinate error nature and location.
• Does not require getName neither getTarget on EventInterface
• SharedEventManager could be removed.

Con:

• Need to compare large strings while filtering the listeners. Anyone knows if PHP it's enough smart for compare two strings by the same memory reference?
• Require to have 1 class per event.
• Makes more difficult wildcard events (could require substring matches)

I'm sorry, I do not do PR. But I'll show you the code.

Event Manager uses the queue.

1. For the experiment, I did a SplPriorityQueue with php. If you add an element to the queue, this leads to complex calculations. But not every Queue will be used by the event manager!!!!!!!

• Therefore, I propose to add items only to the array, but SplPriorityQueue create only when the getIterator() method.

2. Delete operations are very complex in terms of computing. Two or more operations - even worse :)

• The solution is the same. I propose to add items only to the array, but SplPriorityQueue create only when the getIterator() method.

<?php

namespace Zend\Stdlib;

use Countable;
use IteratorAggregate;
use Serializable;

/**
 * Optimized for add and remove operations.
 */
class PriorityQueue implements Countable, IteratorAggregate, Serializable
{
    const EXTR_DATA     = 0x00000001;
    const EXTR_PRIORITY = 0x00000002;
    const EXTR_BOTH     = 0x00000003;

    /**
     * Inner queue class to use for iteration
     * @var string
     */
    protected $queueClass = 'Zend\Stdlib\SplPriorityQueue';

    /**
     * Actual items aggregated in the priority queue. Each item is an array
     * with keys "data" and "priority".
     * @var array
     */
    protected $items      = [];

    /**
     * Inner queue object
     * @var SplPriorityQueue
     */
    protected $queue;

    /**
     * Insert an item into the queue
     *
     * Priority defaults to 1 (low priority) if none provided.
     *
     * @param  mixed $data
     * @param  int $priority
     * @return PriorityQueue
     */
    public function insert($data, $priority = 1)
    {
        $priority = (int) $priority;
        $this->items[] = [
            'data'     => $data,
            'priority' => $priority,
        ];
        return $this;
    }

    /**
     * Remove an item from the queue
     *
     * This is different than {@link extract()}; its purpose is to dequeue an
     * item.
     *
     * This operation is potentially expensive, as it requires
     * re-initialization and re-population of the inner queue.
     *
     * Note: this removes the first item matching the provided item found. If
     * the same item has been added multiple times, it will not remove other
     * instances.
     *
     * @param  mixed $datum
     * @return bool False if the item was not found, true otherwise.
     */
    public function remove($datum)
    {
        $found = false;
        foreach ($this->items as $key => $item) {
            if ($item['data'] === $datum) {
                unset($this->items[$key]);
                $this->queue = null;
                $found = true;
                break;
            }
        }
        return $found;
    }

    /**
     * Is the queue empty?
     *
     * @return bool
     */
    public function isEmpty()
    {
        return (0 === $this->count());
    }

    /**
     * How many items are in the queue?
     *
     * @return int
     */
    public function count()
    {
        return count($this->items);
    }

    /**
     * Peek at the top node in the queue, based on priority.
     *
     * @return mixed
     */
    public function top()
    {
        return $this->getIterator()->top();
    }

    /**
     * Extract a node from the inner queue and sift up
     *
     * @return mixed
     */
    public function extract()
    {
        return $this->getQueue()->extract();
    }

    /**
     * Retrieve the inner iterator
     *
     * SplPriorityQueue acts as a heap, which typically implies that as items
     * are iterated, they are also removed. This does not work for situations
     * where the queue may be iterated multiple times. As such, this class
     * aggregates the values, and also injects an SplPriorityQueue. This method
     * retrieves the inner queue object, and clones it for purposes of
     * iteration.
     *
     * @return SplPriorityQueue
     */
    public function getIterator()
    {
        $queue = $this->getQueue();
        return clone $queue;
    }

    /**
     * Serialize the data structure
     *
     * @return string
     */
    public function serialize()
    {
        return serialize($this->items);
    }

    /**
     * Unserialize a string into a PriorityQueue object
     *
     * Serialization format is compatible with {@link Zend\Stdlib\SplPriorityQueue}
     *
     * @param  string $data
     * @return void
     */
    public function unserialize($data)
    {
        foreach (unserialize($data) as $item) {
            $this->insert($item['data'], $item['priority']);
        }
    }

    /**
     * Serialize to an array
     *
     * By default, returns only the item data, and in the order registered (not
     * sorted). You may provide one of the EXTR_* flags as an argument, allowing
     * the ability to return priorities or both data and priority.
     *
     * @param  int $flag
     * @return array
     */
    public function toArray($flag = self::EXTR_DATA)
    {
        switch ($flag) {
            case self::EXTR_BOTH:
                return $this->items;
            case self::EXTR_PRIORITY:
                return array_map(function ($item) {
                    return $item['priority'];
                }, $this->items);
            case self::EXTR_DATA:
            default:
                return array_map(function ($item) {
                    return $item['data'];
                }, $this->items);
        }
    }

    /**
     * Specify the internal queue class
     *
     * Please see {@link getIterator()} for details on the necessity of an
     * internal queue class. The class provided should extend SplPriorityQueue.
     *
     * @param  string $class
     * @return PriorityQueue
     */
    public function setInternalQueueClass($class)
    {
        $this->queueClass = (string) $class;
        return $this;
    }

    /**
     * Does the queue contain the given datum?
     *
     * @param  mixed $datum
     * @return bool
     */
    public function contains($datum)
    {
        foreach ($this->items as $item) {
            if ($item['data'] === $datum) {
                return true;
            }
        }
        return false;
    }

    /**
     * Does the queue have an item with the given priority?
     *
     * @param  int $priority
     * @return bool
     */
    public function hasPriority($priority)
    {
        foreach ($this->items as $item) {
            if ($item['priority'] === $priority) {
                return true;
            }
        }
        return false;
    }

    /**
     * Get the inner priority queue instance
     *
     * @throws Exception\DomainException
     * @return SplPriorityQueue
     */
    protected function getQueue()
    {
        if (null === $this->queue) {
            $this->queue = new $this->queueClass();
            if (!$this->queue instanceof \SplPriorityQueue) {
                throw new Exception\DomainException(sprintf(
                    'PriorityQueue expects an internal queue of type SplPriorityQueue; received "%s"',
                    get_class($this->queue)
                ));
            }
            foreach ($this->items as $item) {
                $this->queue->insert($item['data'], $item['priority']);
            }
        }
        return $this->queue;
    }

    /**
     * Add support for deep cloning
     *
     * @return void
     */
    public function __clone()
    {
        if (null !== $this->queue) {
            $this->queue = clone $this->queue;
        }
    }
}

Hi @weierophinney, I try to update zendframework/zend-eventmanager - ^2.6.3 to ^3.0.0 main Problem in \Zend\EventManager\SharedEventManager::attach was the return removed. We using this return for caching and detach our events. Is there any migration guide I try to do it by self but I am not sure if this be working as before.

Old:

    /**
     * {@inheritdoc}
     */
 public function attach(EventManagerInterface $events, $priority = 1)
    {
        $sharedEvents = $events->getSharedManager();
        $this->listeners[] = $sharedEvents->attach(
            Application::class,
            MvcEvent::EVENT_BOOTSTRAP,
            [$this, 'onBootstrap'],
            $priority
        );
    }

    /**
     * {@inheritdoc}
     */
    public function detach(EventManagerInterface $events)
    {
        foreach ($this->listeners as $index => $listener) {
            if ($events->detach($listener)) {
                unset($this->listeners[$index]);
            }
        }
    }

New:

 public function attach(EventManagerInterface $events, $priority = 1)
    {
        $sharedEvents = $events->getSharedManager();
        $sharedEvents->attach(
            Application::class,
            MvcEvent::EVENT_BOOTSTRAP,
            [$this, 'onBootstrap'],
            $priority
        );

        $this->listeners = $sharedEvents->getListeners([Application::class],
            MvcEvent::EVENT_BOOTSTRAP);
    }

    /**
     * {@inheritdoc}
     */
    public function detach(EventManagerInterface $events)
    {
        foreach ($this->listeners as $index => $listener) {
                $events->detach($listener);
                unset($this->listeners[$index]);
        }
    }

This patch provides a forwards-compatibility release that adapts zend-eventmanager to work as a PSR-14 EventDispatcher. It does so by doing the following:

• Creating package-specific ListenerProviderInterface and EventDispatcherInterface versions that work with PHP 5.6.
• Moving all listener aggregation into classes within a ListenerProvider subnamespace; this includes both the listener attachment previously in the EventManager instance as well as the SharedEventManager instance.
• Renaming "listener aggregates" to "listener subscribers" in the new ListenerProvider subnamespace.
• Adapting EventManager to consume listener providers. By default, it will create a default priority-based listener provider, and have its various listener attachment methods proxy to that provider; it then aggregates that provider with the SharedEventManager (which is itself a provider now) in order to retrieve listeners. This is done in such a way that behavior is completely backwards compatible with current usage.
  • A new named constructor, createUsingListenerProvider(), allows providing a specific listener provider for use with the EventManager. If the provider is attachment capable, the various listener attachment methods will proxy to it; otherwise, they will raise an exception.

The patch also deprecates a number of features, including:

• Most interfaces, including the EventInterface.
• The entire "shared event manager" concept (this can be accomplished via event object hierarchies instead)

TODO

• [x] Write changelog entries
• [ ] Create documentation of new features
• [ ] Document how to start migrating to the new features in order to prepare for version 4

hi Team,

assuming that an application has factories for its listeners, it would be nice to configure them in a central location and to not pollute the service container. any interest?

thanks : )

hi Team,

do you see any value in a NullListenerAggregate?

i'm using feature toggles in a production app and would like for my listener factory to be able to produce a valid ListenerAggregateInterface but maybe one that doesn't do anything if the behavior in the aspect is disabled via toggle.

maybe there's another way i can solve this problem that i haven't considered.

thank you : )

This PR replaces use of the container-interop package with the PSR-11 container interface. This is obviously a BC break and would need to be released in EventManager 4.0 along with a migration guide.

This PR is being submitted in conjunction with a similar PR on the zend-framework/zend-servicemanager repository. Before merging and releasing the zend-servicemanager PR, this one should be merged and released with a new major version, and the zend-servicemanager should have its Composer dependencies updated to include version 4.0 of zend-eventmanager.

Is there a reason there isn't a Lazy Aggregate for attaching listeners to the Shared Event Manager?

Something like:

class SharedLazyListenerAggregate
{
    ...

    public function attachShared(SharedEventManagerInterface $manager, $priority = 1)
    {
        foreach ($this->lazyListeners as $lazyListener) {
            $this->listeners[] = $manager->attach(
                '*',
                $lazyListener->getEvent(),
                $lazyListener,
                $lazyListener->getPriority($priority)
            );
        }
    }

Ping @bakura10