В
Получается, после мержа того PR этот кейс можно не рассматривать?
Да, добавлю, когда ответ вот на этот вопрос туда засуну)
Size: a a a
2020 October 15
В
чтобы темы не разбивать
AM
Получается, после мержа того PR этот кейс можно не рассматривать?
Ну +-.
AM
Сериализовать может не только оно.
В
А можешь тогда объяснить, каким образом объект попадет в сериализатор, не будучи сконфигурированным в контейнере? Таки до вызова
$container->get() его еще не существует, это только definition.T
AM
TradersVE
Thanks. Need to think about it. Useful.
T
Thanks. Need to think about it. Useful.
👍
В
TradersVE
How many people - so many opinions. There are lots of different things called "events", i.e.:
- some kind of immutable events: if a leaf has fallen from a tree, you can't get it back anymore. Frank de Jonge means these ones.
- some kind of proposal-events: "Hey, listeners, I want to persist these changes to the DB, if someone is against, then speak now or be silent forever". If any listener is against this proposition, the data shouldn't be persisted (
- I'm working on the library for event-driven programming. In fact there are events that trigger another events, that trigger another events... These events are immutable and they may be asynchronous. Despite the fact that I've named them "actions" (to avoid ambiguity increase), they are events by their essence.
In my opinion you should use the tool if it suites your needs instead of invent limitations where they don't exist.
- some kind of immutable events: if a leaf has fallen from a tree, you can't get it back anymore. Frank de Jonge means these ones.
- some kind of proposal-events: "Hey, listeners, I want to persist these changes to the DB, if someone is against, then speak now or be silent forever". If any listener is against this proposition, the data shouldn't be persisted (
return false from beforeSave in Yii2 ActiveRecord).- I'm working on the library for event-driven programming. In fact there are events that trigger another events, that trigger another events... These events are immutable and they may be asynchronous. Despite the fact that I've named them "actions" (to avoid ambiguity increase), they are events by their essence.
In my opinion you should use the tool if it suites your needs instead of invent limitations where they don't exist.
СП
How many people - so many opinions. There are lots of different things called "events", i.e.:
- some kind of immutable events: if a leaf has fallen from a tree, you can't get it back anymore. Frank de Jonge means these ones.
- some kind of proposal-events: "Hey, listeners, I want to persist these changes to the DB, if someone is against, then speak now or be silent forever". If any listener is against this proposition, the data shouldn't be persisted (
- I'm working on the library for event-driven programming. In fact there are events that trigger another events, that trigger another events... These events are immutable and they may be asynchronous. Despite the fact that I've named them "actions" (to avoid ambiguity increase), they are events by their essence.
In my opinion you should use the tool if it suites your needs instead of invent limitations where they don't exist.
- some kind of immutable events: if a leaf has fallen from a tree, you can't get it back anymore. Frank de Jonge means these ones.
- some kind of proposal-events: "Hey, listeners, I want to persist these changes to the DB, if someone is against, then speak now or be silent forever". If any listener is against this proposition, the data shouldn't be persisted (
return false from beforeSave in Yii2 ActiveRecord).- I'm working on the library for event-driven programming. In fact there are events that trigger another events, that trigger another events... These events are immutable and they may be asynchronous. Despite the fact that I've named them "actions" (to avoid ambiguity increase), they are events by their essence.
In my opinion you should use the tool if it suites your needs instead of invent limitations where they don't exist.
How do I work with such events in the app? Should be two eventdispatcher: for immutable events and for proposal-events?
В
How do I work with such events in the app? Should be two eventdispatcher: for immutable events and for proposal-events?
I think it's responsibility of an event, not a dispatcher. Event dispatching it the same for the both types of events. But an event can be mutable or not.
СП
I think it's responsibility of an event, not a dispatcher. Event dispatching it the same for the both types of events. But an event can be mutable or not.
Bad subscriber can create modified event by immutable event and return him
В
Bad subscriber can create modified event by immutable event and return him
Yes, if event is passed by reference to such a listener, it can be replaced. This is bad in my opinion.
В
But it is limitation of php itself
В
we can't avoid it
СП
Why?
Dispatcher which send all subscribers immutable event.
Dispatcher which send all subscribers immutable event.
В
For now PSR-14 allows to return changed event from
dispatch method.СП
For now PSR-14 allows to return changed event from
dispatch method.yes) this is limit PSR-14, not PHP
В
Why?
Dispatcher which send all subscribers immutable event.
Dispatcher which send all subscribers immutable event.
fn (&$event) => $event = new AnotherEvent();СП
final class Dispatcher implements EventDispatcherInterface
{
private ListenerProviderInterface $listenerProvider;
public function __construct(ListenerProviderInterface $listenerProvider)
{
$this->listenerProvider = $listenerProvider;
}
public function dispatch(object $event): object
{
foreach ($this->listenerProvider->getListenersForEvent($event) as $listener) {
$listener(clone $event);
}
return $event;
}
}