Kellanved wrote:No, it is because the point of modules is to be independent from changes to the core.
the general assumption is that all MODs are at their newest version.
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.
No, because it is pointless trying to come up with a list of all incompatibilities and side effects.
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.
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.
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.
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.
This is more about the design of particular hooks than the system; please post RFCs for the hooks once we are in that phase.
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.
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.
"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.
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.
There is a more important issue here, which is that on-demand creation of hooks is not going to work 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.