Why is a new events system needed?
I have updated this section, thanks.
No measurements were done because there is no code yet. The new events would also contain more data/functionality, and a lot more events would be triggered. We would need to measure the total performance gain/loss for events and logging at the same time. I suppose it is going to be slower in the end, but there would be a lot more flexibility and predictability which may be itself worth something.
Base class would define mandatory list of properties and preset some values and do basic data validation. Plugin event classes implement backwards compatibility for old logging and old events, they set all required information and store one custom data field. They might also contain other functionality such as access control, rendering for reports, etc.
We have tried to explain/describe it in the spec, I agree it may not be clear. I suppose you could help us to explain the benefits there using your perfect English language skills and OOP knowledge.
"Callable" is a type hint in PHP 5.4. It is used in PHP manual when describing callbacks, so "callback" is probably better, changing it. Observer or handler is problematic because the whole array is observer, your suggestion is worse because observer->observer is poor design - it must indicate that devs need to put function name or class::method there. Let's not start beating the PHP type system, we all know that 1/0 or true/false makes no difference - fixed in examples.
The current event system uses only event name and arbitrary event data, the event data is not documented much, it is doing database queries - pretty much anything else must be better, right?
"Developers of observers must make sure that execution does not end with a fatal error under any condition" - Current event handling fails badly if handler triggers exception, which happens during upgrades already. Your question about fatal errors is strange. We had that problem already, the difference is when observer gets execute before plugin installation (which makes it actually a bit more usable). Missing DB tables cause exceptions, not fatal errors - so it should not be a problem.
The list of handlers was fetched from database or MUC - it is both slow and inaccurate at the moment. Yes, it will be faster if we fix&improve the current listing of all plugins and then store the results only in MUC or in simple php file in dataroot. It must be faster and more accurate.
Cron event processing must not be time confusing, we already have enough task there, so yes they are abused in portfolio. The data objects are often out of data, such as in file instances in assignment cron events. Cron events were not supposed to be used for moving of time consuming tasks form current page to cron, they were intended as a fallback when handlers for some reasons failed event processing - this whole concept did not work much and was causing performance issues.
You are wrong, event_manager()->trigger($event) would be far worse design because we would have to open public api in event base class, $event->trigger() allows us to lock down the event so that it is not triggered twice or altered after triggering - it must stay unchanged because of the new execution order and buffering, most of the things are protected and they are supposed to be modified from init() method only. This is actually the main reason for extending of base class.
Decision: Use separate class for each event
Please watch your language, porn stars suck, class design does not. Inheritance seems to be perfectly valid for events where we want to enforce the structure and let extending class only add extra behaviour and legacy data. Extending in this particular case is in my opinion less error-prone. Your objections are just a general OOP talk, show me some more if you want to persuade me.
Reviews - you look at 1 file only and you see everything related to one particular event, you do not need to grep the codebase and verify where it is used to make sure thad developers set legacy logging/events everywhere, that they filled the same levels and crud everywhere, etc. Integration - integrators would know that any changes in event classes must be closed watched for BC issues. Again your objections are too general, you do not give any valid reasons to do it some other way. You also did not describe how you would do it, how am I supposed to argue with "generic object" approach? Nobody explained how that could possibly work yet.
"All data would have to be calculated even if it is not used."?
Some event properties are optional, they may not be needed at all when triggering it - legacy logs, legacy events, affected users, access control, etc. These are exposed via methods that might have to event access database to get the values. Of course developers may decide to store them as property in their init method. The point here is that methods give us room to improve performance here, the general objects do not, sorry.
Using class names as event names prevents typos or hacking with event names, the more we validate in PHP itself the faster it will be (this validates file location, file name and class name for free if you ignore class loader cost). But yes, we would have $event->name() too, it would always return the class name.
The available events should be documented somewhere, somebody proposed to register the events somehow, the problem is when you get the raw data from logs and you want to create the original instance of the event, the class loader with frankenstyle makes this trivial.
I suppose once you stop opposing the "single frankenstyle class per event extending base" concept you might realise that it magically solves many problems we would face otherwise. My code demo linked from the spec hopefully proves that.
Thanks for your comments!!!