We apologize for the instability of composr.app and appreciate your patience. We are working on the statistics addon and trying to find an optimal way to store and render data. Unfortunately, we have yet to find a solution that can handle the traffic (and therefore, tens of millions of statistical records) of composr.app. We're working hard on one.
I was thinking whether this is an opportunity to make all the hooks implement a class interface. From a code quality point of view it would be an improvement, with minimal code complexity cost due to it being wrappable inside the new API.
However, I don't like the performance implications. For each hook type we'd need to load up another file that defines the interface, then PHP would need to check interface rules at run-time. That's actually not at all trivial - if you consider a page using 20 hook types, that's 20 extra PHP files loaded. So I think it's best to leave that. It makes more sense for compiled languages.
However, I don't like the performance implications. For each hook type we'd need to load up another file that defines the interface, then PHP would need to check interface rules at run-time. That's actually not at all trivial - if you consider a page using 20 hook types, that's 20 extra PHP files loaded. So I think it's best to leave that. It makes more sense for compiled languages.