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).
On Mon, Aug 20, 2018 at 10:38 AM <designc...@gmail.com> wrote:
> 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)?
>
> On Monday, August 20, 2018 at 8:27:10 PM UTC+5, Woody Gilk wrote:
>>
>> 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
>>
>> --
>> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@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
> <https://groups.google.com/d/msgid/php-fig/8158bd9b-3458-4f55-94e9-d489f19fe87e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAJp_myWqtUv2XNZDimWWLG9upt7hGCcgOmDya52Rympub31QxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
