Kellanved wrote: No, it is because the point of modules is to be independent from changes to the core.
I don't know how else I can convey this to you, but what should be and what is are two different things. Core will change and break modifications. People will run old versions for a nontrivial amount of time. People do update their modified boards in pieces. This is the reality that you are ignoring. I can only hope that someone else is more persuasive.the general assumption is that all MODs are at their newest version.
This is why conflicts are made optional, just like version number ranges and dependencies. If a mod author does not want to use them, they don't have to. This functionality exists for mod authors who want to support easy upgrading and who are concerned with compatibility.No, because it is pointless trying to come up with a list of all incompatibilities and side effects.
You simply need to scroll up to my first post in this thread and try to understand where I'm coming from. Everything I posted was a result of experience using and modifying phpbb in particular as well as other software. I didn't make that stuff up just now.Interesting, where do you see the mismatch? Care to expand on the subject? Feedback is the sole reason for this topic being here and if you see a pressing problem, please share.
Maybe you think you are obligated to implement everything anyone proposes. This is not true. There is a difference between saying "I don't need feature X, and I won't code it, but if you want it and you implement it, I will accept it" and "feature X is useless and will not be included regardless of how you feel about it". The former is perfectly acceptable, the latter is, well, read the paragraph about upstream in this post.
No software should be built in isolation from its users. Users of hook system are hooks. To build a hook system and then consider how to implement hooks for that system (which is what I think you mean by "once we are in that phase", please correct me if I'm wrong) is absurd.This is more about the design of particular hooks than the system; please post RFCs for the hooks once we are in that phase.
"It just works" and scalability are not contrary, in fact, they have nothing to do with each other. Putting unnecessary code into critical path is not good because you increase the working set size, you make the code harder to audit, you make the code harder to optimize because it does irrelevant operations, etc.There is no conflict with scalability at all, quite the contrary. The "it just works" factor is extremely important for hook systems, if they are to be adopted - I won't introduce any more descriptors than absolutely required.
There is a more important issue here, which is that on-demand creation of hooks is not going to work at all.The creation of a hook is nothing more than the insertion of one row into a table in case of an key not being defined - I don't see any scalability issues at all.
If there are two mods, A and B, and A creates a hook which B uses, and A and B are installed together (that is, user installs A and immediately after installs B, perhaps because they really want B and A is B's prerequisite), then B's installation will attempt to resolve hook from A which does not exist because A's code was never run. Allowing linking to nonexistent hooks will make troubleshooting legitimate misspellings of references and missing dependency specifications unnecessarily hard, and running A's code so it can register its hooks is an epic kludge compared to simply asking A for a list of hooks it defines.