On 09/04/20 at 12:22pm, Allan McRae wrote: ...
I'm trying to figure out how includes would address this problem.
We have a hook that runs when its triggers are met. We want to have a package add additional triggers, by dropping in a file into our config, but do not want to duplicate the function of the hook, or to directly edit the hook. An Include would provide a place where we can drop more config files with (e.g.) more triggers, but that requires the original hook to be set up such that it is extendable. Just adding additional triggers does not require the original hook to do anything.
Requiring the hook to opt-in to this behavior is the point. Once you make a hook extensible, making any changes to that hook become much more difficult because those changes could render any extensions useless, and the hook author doesn't have any way to know if anything else is depending on the current implementation. Requiring the hook to opt-in gives the author a way to indicate that the hook is suitable for extension and won't change in a way that breaks those extensions in the future. Essentially we're allowing a hook to choose to provide a public interface instead of automatically doing it for all hooks. And, of course, the fact that we already have code to deal with Includes is a nice plus.