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)));
thoughts?
On Monday, August 20, 2018 at 7:50:46 PM UTC+5, Woody Gilk wrote:
>
> On Mon, Aug 20, 2018 at 8:44 AM <[email protected] <javascript:>> 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
>
> >
> > as the event name could easily be retrieved like in the emit method
> using "get_class($event);" -- any thoughts?
> >
> > On Tuesday, July 10, 2018 at 12:07:42 AM UTC+5, Larry Garfield wrote:
> >>
> >> 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
> >>
> > --
> > 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 [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > 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.
>
On Monday, August 20, 2018 at 7:50:46 PM UTC+5, Woody Gilk wrote:
>
> On Mon, Aug 20, 2018 at 8:44 AM <[email protected] <javascript:>> 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
>
> >
> > as the event name could easily be retrieved like in the emit method
> using "get_class($event);" -- any thoughts?
> >
> > On Tuesday, July 10, 2018 at 12:07:42 AM UTC+5, Larry Garfield wrote:
> >>
> >> 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
> >>
> > --
> > 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 [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > 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.
>
On Monday, August 20, 2018 at 7:50:46 PM UTC+5, Woody Gilk wrote:
>
> On Mon, Aug 20, 2018 at 8:44 AM <[email protected] <javascript:>> 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
>
> >
> > as the event name could easily be retrieved like in the emit method
> using "get_class($event);" -- any thoughts?
> >
> > On Tuesday, July 10, 2018 at 12:07:42 AM UTC+5, Larry Garfield wrote:
> >>
> >> 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
> >>
> > --
> > 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 [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > 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.
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/fca20cf0-587a-43a6-8d12-8c24bfb9413b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
