by Mark Nielsen.
Hey Petr, thanks for the quick reply. I'm going to try to change your mind ;)
- I would say that events are general, in that the data associated to them could often be exactly the same. The only difference is the name. For example, assignment submission event would be the same data (I would think) but the name would be submission_updated, submission_created and submission_deleted (or w/e they are). Maybe I'm not seeing something here, could you point in the spec where this would break down?
- The triggering does not need to be inside the event to protect properties because the event class itself can do this by only providing getters for readonly properties. I think observers modifying event data is a highly valuable use case. EG: you could provide inexpensive hooks into core processes that could change the behavior of Moodle. This would be very valuable for partners as they could customize key parts of Moodle without having to patch it. This makes upgrades much easier. This is how modern frameworks stay thin yet flexible.
- I feel like at some point, there would be some filtering at one end or the other (EG: in the observer). I was literally thinking of something like this in the event triggering code: if $event instanceof loggable_event_interface then create new log event and fire it. A double hop, but not really an expensive double hop AFAIK. I think Tim's idea is also interesting, but not sure how to do that without it being a double hop for every event fired.
- Cool!
In the end, I feel like the current design has some limitations for usage in other use cases. It seems like what is being built is not a event system, but a logging system that we can subscribe to. Perhaps that's the goal, but I feel like this is an opportunity to get a great event framework in place that has the ability to be used in a wide variety of use cases.
Thanks for listening, Cheers, Mark.