[PSR-14] Alpha 1

[Larry Garfield]

In the last thread it was noted that the Working Group didn't have much
formally published to comment on, which meant some of our meeting notes
weren't entirely clear. Fair point! So let's fix that.

We've merged the rough current state of our thinking to the standards repo and
the code repo. This is NOT final code for PSR-14. Alpha 1 is probably the
best description. Most things are still up for debate at this point although
I like the direction we seem to be settling.

The biggest change is splitting the dispatcher into 3 different variants.
That is based primarily on a Slack discussion Monday in response to the
feedback about the name "Events". We're still using "events" as the name but
the split does acknowledge that there are different distinct workflows that
are nonetheless all still related.

Here's the spec:

https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
https://github.com/php-fig/event-dispatcher/tree/master/src

We have a number of skunkworks implementations that have been built or mostly
built as we go. The 3 most up to date are:

My latest work, which is pre-split so a bit old but shows a variety of
different registration mechanisms:

https://github.com/php-fig/event-dispatcher/blob/crell-rabbithole/
RABBITHOLE.md

The latest prototype from MWOP:

https://github.com/php-fig/event-dispatcher/tree/mwop-mk4

And Benni's experimentation:

https://github.com/php-fig/event-dispatcher/tree/benni-separate

The spec draft is the most up to date, though, and in case of dispute that
should be considered our latest thinking.

Hopefully that clarifies a bit where we are and offers something more precise
to comment on as appropriate.

--Larry Garfield, PSR-14 Editor

[desig...@gmail.com]

So I've been digging into the implementations and so far really like Benni's implementation for its sheer simplicity. The only thing I'd like to point out is that in the EventManager::emit() method the name of the event is retrieved like this: "get_class($event);" which makes sense if we have classes by the name of the events (e.g. StatusUpdatedEvent.php, etc.) as opposed to a generic Event class that we pass an event name to. If we go by this logic, then shouldn't:

"public function attach(string $eventName, callable $listener): void"

"public function getListenersForEvent(string $eventName): ?array"

be changed to the following:

"public function attach(EventInterface $event, callable $listener): void"

"public function getListenersForEvent(EventInterface $event): ?array"

as the event name could easily be retrieved like in the emit method using "get_class($event);" -- any thoughts?

[desig...@gmail.com]

Sorry, following up on my last post, we could even introduce a __toString() method to get the event name from EventInterface instances; in that regard, how about including __toString() in the EventInterface for a hard requirement?

[Woody Gilk]

On Mon, Aug 20, 2018 at 8:44 AM <desig...@gmail.com> wrote:
>
> So I've been digging into the implementations and so far really like Benni's implementation for its sheer simplicity. The only thing I'd like to point out is that in the EventManager::emit() method the name of the event is retrieved like this: "get_class($event);" which makes sense if we have classes by the name of the events (e.g. StatusUpdatedEvent.php, etc.) as opposed to a generic Event class that we pass an event name to. If we go by this logic, then shouldn't:
>
> "public function attach(string $eventName, callable $listener): void"
> "public function getListenersForEvent(string $eventName): ?array"
>
> be changed to the following:
>
> "public function attach(EventInterface $event, callable $listener): void"
> "public function getListenersForEvent(EventInterface $event): ?array"

No, because the event object is not known until it is created, only
the TYPE is known.

--
Woody Gilk
https://shadowhand.me

> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/dff5c44e-df5b-4dc7-bf3f-b32dba8f920a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[desig...@gmail.com]

Right. In that case, the string $eventName would have to be a fully qualified event class name (including the namespace) for the emitter to pick it up correctly. Isn't that a bit impractical? Or should we just be looking at the event name and stripping off the namespace (in emitter) like maybe by doing something like:

$eventName = end(explode('\\', get_class($event)));

thoughts?

[Woody Gilk]

On Mon, Aug 20, 2018 at 10:16 AM <desig...@gmail.com> wrote:
>
> Right. In that case, the string $eventName would have to be a fully qualified event class name (including the namespace) for the emitter to pick it up correctly. Isn't that a bit impractical? Or should we just be looking at the event name and stripping off the namespace (in emitter) like maybe by doing something like:
>

> $eventName = end(explode('\\', get_class($command)));

I don't think it is impractical at all. Mapping by full class name is
very easy with `Foo::class` and FQCN prevents duplicate errors, eg:

Acme\Domain\Task\UpdatedEvent
Acme\Domain\User\UpdatedEvent

[desig...@gmail.com]

To use `::class`, the event object must have already been created. To that I wonder if, when attaching events to listeners by name, should this really be a hard requirement (i.e. the event object being created)?

[Matthew Weier O'Phinney]

Just as an FYI: This discussion is essentially moot with recent revisions of the spec.

We are not defining listener attachment as part of the spec at this time, as there are SOOOOO many ways to accomplish it. Instead, we are defining a `ListenerProviderInterface`, with the single method `getListenersForEvent(EventInterface $event) : iterable`. It is then up to implementations to determine how to populate the set of listeners.

Why are we not defining attachment? Because there's no one way to define it:

- You could do reflection on the callable to determine what the argument to it is in order to determine what it can listen to.

- You could accept an event class name as an argument, along with the listener.

- You could accept an event INSTANCE as an argument, along with the listener.

- You might want to attach listeners using a priority integer, to allow ordering listeners (useful only for the `TaskProcessorInterface`).

- You might want to allow operations such as "first", "last", "before", "after", etc. as mechanisms for ordering listeners (again, only for use with the `TaskProcessorInterface`).

- You might want to allow lazy-loading (i.e., instead of passing a listener callable, you pass a service name and/or a method on that service to call).

There are a ton of options, and we cannot feasibly cover them all in the spec. We CAN cover how to retrieve listeners for the event being dispatched, however. We will LIKELY provide interfaces and/or implementations of providers with different attachment methods in our util package, but these are not and will not be covered by the specification.

Finally, we do not allow arbitrary string event names nor do we define something like a `getName()` method on events. The fully-qualified class name of the event type is definitely enough here, and there are plenty of existing systems out there that demonstrate its effectiveness (e.g., Composer's internal events!). Contrary to your last assertion, `::class` does NOT require an instance to access; you can access it using the FQCN: `Foo\Bar\BazEvent::class`. When the class is imported into the current file, then this becomes even more succinct: `BazEvent::class`. If you HAVE an instance already, great — but for the common case of attaching listeners, you can use one of these FQCN notations instead.

Yes, it DOES require a class is defined, which eliminates the possibility of anonymous class implementations of events... UNLESS they implement specific interfaces. In that situation, your listeners can attach using the interface name (which can ALSO be identified by `::class` notation).

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8158bd9b-3458-4f55-94e9-d489f19fe87e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Daniel Hunsaker]

Wait, `::class` works on objects?

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8158bd9b-3458-4f55-94e9-d489f19fe87e%40googlegroups.com.

[Woody Gilk]

On Mon, Aug 20, 2018 at 10:38 AM <desig...@gmail.com> wrote:
>
> To use `::class`, the event object must have already been created.

That is incorrect, the following is entirely valid:

use Acme\Domain\User\UserUpdatedEvent;

$class = UpdatedEvent::Class;

[desig...@gmail.com]

Yes, sorry. You're right, I totally forgot the usage. It's been a long day.

[Benjamin Mack]

Hi everybody.

One more note from my side for clarification: the ::class does not trigger the auto loading mechanism to check if a class is available or not. So you can listen to any kind of events on e.g. libraries your package has no hard dependency on.

All the best,
Benni

> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6J4Z1NfLP3Kmq-9aY8CSdGk78%2B%3DLdmz3puHegHjX3k7CA%40mail.gmail.com.

[desig...@gmail.com]

Anyone know when Alpha 2 comes out? Really looking forward to where this goes. Or, if anyone can share a link to their alpha-2 implementations, I would love to have a look.

Thanks!

[Larry Garfield]

Greetings.

See the latest meeting notes I just sent a moment ago. They include a link to
all the relevant things, including sample implementations built against the
0.3.0 version. I also just tagged 0.4.0 today, which if you want to try it
out (which I encourage!) is what you should be using.

--Larry Garfield

On Monday, August 20, 2018 11:32:54 AM CDT desig...@gmail.com wrote:
> Anyone know when Alpha 2

> <https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/ph
> p-fig/Wi3BVClQb6Q/SvWlOwcmAQAJ> comes out? Really looking forward to where

> this goes. Or, if anyone can share a link to their alpha-2 implementations,
> I would love to have a look.
>
> Thanks!
>
> On Monday, August 20, 2018 at 9:20:17 PM UTC+5, Benni Mack wrote:
> > Hi everybody.
> >
> > One more note from my side for clarification: the ::class does not trigger
> > the auto loading mechanism to check if a class is available or not. So you
> > can listen to any kind of events on e.g. libraries your package has no
> > hard
> > dependency on.
> >
> > All the best,
> > Benni
> >

> > > On 20. Aug 2018, at 18:03, Woody Gilk <woody...@gmail.com <javascript:>>
> >
> > wrote:
> > >> On Mon, Aug 20, 2018 at 10:38 AM <desig...@gmail.com <javascript:>>

> >
> > wrote:
> > >> To use `::class`, the event object must have already been created.
> > >
> > > That is incorrect, the following is entirely valid:
> > >
> > > use Acme\Domain\User\UserUpdatedEvent;
> > >
> > > $class = UpdatedEvent::Class;
> >

> > Groups "PHP Framework Interoperability Group" group.
> >
> > > To unsubscribe from this group and stop receiving emails from it, send
> >

> > an email to php-fig+u...@googlegroups.com <javascript:>.

> >
> > > To post to this group, send email to php...@googlegroups.com
> >

> > <javascript:>.

[Larry Garfield]

Another addendum: I just updated Tukio (my PSR-14 experimental library) for
the 0.4.0 version. The tests should provide a reasonable overview of using
it. Just check it out and run vendor/bin/phpunit to see it in action.

--Larry Garfield