Implement PSR-14 in favor of signal/slot

[sorenmalling]

As a follow up, on our Neos & Flow future talk on the Dresden sprint.

The topic about using already existing PHP libraries was brought up on several occasions.

I hereby propose to implement PSR-14, with event dispatcher and corresponding events, as a core feature of Flow.

For my current project, I've created a package using Symfony Event Dispatcher, with resolving of events and listener, based on a Interface, so a POC can be for the functionality can be proposed in a short time

By implementing PSR-14 we move one step closer to the PHP FIG workgroup. At the same time, we are "slicing the elephant", by making Flow independent of a signal/slot library, we only can maintain ourself (as a project), and making use of the open source community of Symfony.

Requirements

• [ ] Deprecate signal/slot
• [ ] Replace signals with Event
• [ ] Make backward compatibility layer, for forming Signals into events?
• [ ] Remove signal/slot (next(+1?) version of Flow)

[robertlemke]

Thanks for taking care of this topic!

In my opinion, events and Signal / Slot are different concepts. While Signal / Slot is a very simple implementation of the Observer Pattern, there's much more complexity (and feature-richness) in the area of events. They certainly play in the similar area, but behave a bit differently and are intended for different purposes.

So my first question would be: Why would we have to remove Signal / Slot in order to introduce PSR-14 support?

Just having spent two months of coding to adjust my code base to some inconspicuous changes in the Event Sourcing package, I am again quite attentive when it comes to breaking changes of a Flow feature which has been many years around. There must be very good reasons or a very easy migration path, in my opinion, to justify such a step.

[kitsunet]

The wording is unfortunate but I would understand PSR-14 events as a description of the observer pattern and as such feels like a good generalization of our signal/slot system. As a next step in getting more open and supporting standards I find this a good idea. Obviously breakiness should be kept minimal.

[albe]

Without looking very deeply into it for plausibililty, my optimal scenario would be that we integrate PSR-14 as the underlying implementation of our own Signal/Slot mechanic (through the compilation step if needed?) in such a way, that someone could implement the exact same behaviour (indistinguishable for the runtime) without using @Flow\Signal and just writing PSR-14 style code manually.

So, Flow style Signal/Slot should in the end provide some convenience or additional value over manually written PSR-14. So I would not necessarily want to deprecate/phase out Signal/Slot, but I'm all in favor of making PSR-14 a well integrated mechanic in Flow