Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide duck-typed PSR-14 implementation #2

Open
1 of 3 tasks
weierophinney opened this issue Dec 31, 2019 · 4 comments · May be fixed by #12
Open
1 of 3 tasks

Provide duck-typed PSR-14 implementation #2

weierophinney opened this issue Dec 31, 2019 · 4 comments · May be fixed by #12

Comments

@weierophinney
Copy link
Member

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

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

Originally posted by @weierophinney at zendframework/zend-eventmanager#73

@acelaya
Copy link

acelaya commented Jul 16, 2020

Hey!

Is there any plan to continue working on this? I see there was some work done on the old zendframework repo, but the pull request was not migrated to this one.

I'm asking because I plan to support both laminas-eventmanager and PSR-14 in a project of mine, and having this would drastically simplify things, haha.

I know there's a lot of work yet to be done in other packages, so I don't want to sound picky. I would just want to know if we are talking about a one month thing, a six month thing or a one year thing, just to decide if it's worth waiting or going with my own temporal implementation.

I'm also open to help with this if there's anything I can do.

@weierophinney
Copy link
Member Author

@acelaya Well, clearly at this point, it's at least a six month thing. 🤣

I'd forgotten how much work I did on the original, and it's definitely a good starting place. I'll see if I can get some work done on it in the coming weeks, so we can get a v3 release with it in, and potentially prepare for a v4 release.

@weierophinney weierophinney linked a pull request Jan 8, 2021 that will close this issue
3 tasks
@weierophinney
Copy link
Member Author

@acelaya See #12 - since 3.4.0 targets 7.3+, I was able to do a pretty straight implementation, instead of requiring duck-typing.

@acelaya
Copy link

acelaya commented Jan 9, 2021

Thanks for checking this now @weierophinney!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants